WiMAX Forum Network Architecturewimaxforum.org/sites/wimaxforum.org/files/technical_document/2010/12/WMF-T32-001...Jul 03, 2012 · EXTENT P ERMITTED B Y LA W, TH E WiMAX FORUM14

WiMAX FORUM PROPRIETARY

WiMAX Forum® Network Architecture

Architecture Tenets, Reference Model and Reference Points

Base Specification

WMF-T32-001-R016v01 WiMAX Forum® Approved

(2010-11-30)

WiMAX Forum Proprietary Copyright © 2010 WiMAX Forum. All Rights Reserved.

WiMAX Forum® Network Architecture WMF-T32-001-R016v01 Network-Stage2-Base

Page - i


Copyr ight Notice, Use Restr ictions, Disclaimer , and Limitation of Liability. 1

2 Copyright 2010 WiMAX Forum. All rights reserved. 3 4 The WiMAX F orum® owns t he c opyright i n t his doc ument a nd r eserves a ll r ights he rein. This doc ument i s available for 5 download from the WiMAX Forum and may be duplicated for internal use, provided that all copies contain all proprietary notices 6 and d isclaimers i ncluded herein. E xcept f or t he f oregoing, t his doc ument m ay not be du plicated, i n w hole or i n pa rt, or 7 distributed without the express written authorization of the WiMAX Forum. 8 9 Use of this document is subject to the disclaimers and limitations described below. Use of this document constitutes acceptance 10 of the following terms and conditions: 11 12 THIS DO CUMENT I S P ROVIDED “ AS I S” AND W ITHOUT W ARRANTY O F ANY K IND. T O T HE G REATEST 13 EXTENT P ERMITTED B Y LA W, TH E WiMAX FORUM DISCLAIMS AL L E XPRESS, I MPLIED AND 14 STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF TITLE, 15 NONINFRINGEMENT, M ERCHANTABILITY AND F ITNESS F OR A P ARTICULAR PURPOSE. THE W iMAX 16 FORUM DOES N OT W ARRANT TH AT TH IS D OCUMENT I S C OMPLETE O R W ITHOUT ER ROR A ND 17 DISCLAIMS ANY WARRANTIES TO THE CONTRARY. 18 19 Any pr oducts or s ervices pr ovided us ing t echnology de scribed i n or i mplemented i n c onnection w ith t his document m ay be 20 subject t o v arious r egulatory c ontrols under t he laws a nd r egulations of v arious g overnments worldwide. T he us er i s s olely 21 responsible for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all 22 required authorizations, permits, or licenses for its products and/or services as a result of such regulations within the applicable 23 jurisdiction. 24 25 NOTHING I N T HIS DOCUMENT C REATES ANY WARRANTIES WHATSOEVER R EGARDING T HE 26 APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR REGULATIONS OR THE SUITABILITY 27 OR NON-SUITABILITY OF ANY SUCH PRODUCT OR SERVICE FOR USE IN ANY J URISDICTION. 28 29 NOTHING I N T HIS DOCUMENT C REATES ANY WARRANTIES WHATSOEVER R EGARDING T HE 30 SUITABILITY O R NO N-SUITABILITY O F A P RODUCT O R A S ERVICE F OR C ERTIFICATION U NDER ANY 31 CERTIFICATION PROGRAM OF THE WiMAX FORUM OR ANY THIRD PARTY. 32 33 The W iMAX F orum ha s not i nvestigated or m ade a n i ndependent de termination r egarding t itle or n oninfringement of a ny 34 technologies that may be incorporated, described or referenced in this document. Use of this document or implementation of any 35 technologies de scribed or r eferenced he rein m ay t herefore i nfringe undi sclosed t hird-party p atent r ights o r o ther in tellectual 36 property rights. The user is solely responsible for making all assessments relating to title and noninfringement of any technology, 37 standard, or s pecification r eferenced i n this document a nd f or obtaining a ppropriate a uthorization t o us e s uch t echnologies, 38 technologies, standards, and specifications, including through the payment of any required license fees. 39 40 NOTHING I N T HIS DO CUMENT C REATES ANY W ARRANTIES O F T ITLE O R NO NINFRINGEMENT W ITH 41 RESPECT TO ANY TECHNOLOGIES, STANDARDS OR SPECIFICATIONS REFERENCED OR INCORPORATED 42 INTO THIS DOCUMENT. 43 44 IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO THE USER OR TO A THIRD 45 PARTY F OR ANY C LAIM AR ISING F ROM O R RELATING T O T HE USE O F T HIS DOCUMENT, I NCLUDING, 46 WITHOUT L IMITATION, A C LAIM T HAT S UCH US E I NFRINGES A T HIRD P ARTY’S I NTELLECTUAL 47 PROPERTY R IGHTS O R T HAT I T F AILS TO COMPLY W ITH APPLICABLE LAWS O R R EGULATIONS. B Y 48 USE O F T HIS DO CUMENT, THE USER W AIVES ANY S UCH C LAIM AG AINST T HE W iMAX FORUM AND I TS 49 MEMBERS RELATING TO THE USE OF THIS DOCUMENT. 50 51 The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole discretion. The user is 52 solely responsible for determining whether this document has been superseded by a later version or a different document. 53 54

“WiMAX,” “M obile W iMAX,” “Fixed W iMAX,” “ WiMAX F orum,” “WiMAX C ertified,” “ WiMAX F orum C ertified,” t he 55 WiMAX Forum logo and the WiMAX Forum Certified logo are trademarks or registered trademarks of the WiMAX Forum. All 56 other trademarks are the property of their respective owners. Wi-Fi® is a registered trademark of the Wi-Fi Alliance. 57

58


Page - ii


TABLE OF CONTENTS 1

1. INTRODUCTION AND SCOPE ....................................................................................................................... 1 2

2. ABBREVIATIONS/ACRONYMS, DEFINITIONS, AND CONVENTIONS ................................................ 2 3

2.1 DEFINITIONS ................................................................................................................................................... 2 4 2.1.1 AAA ........................................................................................................................................................ 2 5 2.1.2 Access Service Network (ASN)............................................................................................................... 2 6 2.1.3 Accounting Agent ................................................................................................................................... 2 7 2.1.4 Admission Control ................................................................................................................................. 2 8 2.1.5 Application Service Provider (ASP) ...................................................................................................... 2 9 2.1.6 AR .......................................................................................................................................................... 3 10 2.1.7 ASN Anchored Mobility ......................................................................................................................... 3 11 2.1.8 ASN Mobility .......................................................................................................................................... 3 12 2.1.9 Authenticator ......................................................................................................................................... 3 13 2.1.10 Base Station ........................................................................................................................................... 3 14 2.1.11 Channel Plan ......................................................................................................................................... 3 15 2.1.12 Connectivity Service Network (CSN) ..................................................................................................... 3 16 2.1.13 Contractual Agreement Preference List (CAPL) ................................................................................... 4 17 2.1.14 CR .......................................................................................................................................................... 4 18 2.1.15 CSN Anchored Mobility ......................................................................................................................... 4 19 2.1.16 E-LAN Service ....................................................................................................................................... 4 20 2.1.17 E-Line Service ........................................................................................................................................ 4 21 2.1.18 E-Tree Service ....................................................................................................................................... 4 22 2.1.19 Ethernet Support .................................................................................................................................... 4 23 2.1.20 Firewall ................................................................................................................................................. 5 24 2.1.21 Fixed Access .......................................................................................................................................... 5 25 2.1.22 Home Network Service Provider (H-NSP) ............................................................................................. 5 26 2.1.23 Integrated ASN ....................................................................................................................................... 5 27 2.1.24 Internet Access ....................................................................................................................................... 5 28 2.1.25 Internet-working Function ..................................................................................................................... 5 29 2.1.26 IP Header Compression ......................................................................................................................... 5 30 2.1.27 IP Support .............................................................................................................................................. 6 31 2.1.28 IPv4 Support .......................................................................................................................................... 6 32 2.1.29 IPv6 Access Router (AR) ........................................................................................................................ 6 33 2.1.30 IPv6 Support .......................................................................................................................................... 6 34 2.1.31 Location-Based Service (LBS) ............................................................................................................... 6 35 2.1.32 Media Gateway ...................................................................................................................................... 6 36 2.1.33 MIP based Ethernet ............................................................................................................................... 6 37 2.1.34 Mobility Access ...................................................................................................................................... 7 38 2.1.35 Mobility Access Classifier ..................................................................................................................... 7 39 2.1.36 Mobile Station (MS) ............................................................................................................................... 7 40 2.1.37 NAP Based Channel Plan ...................................................................................................................... 7 41 2.1.38 NAS ........................................................................................................................................................ 7 42 2.1.39 Network Access Provider (NAP) ............................................................................................................ 7 43 2.1.40 Network Discovery and (Re)selection .................................................................................................... 7 44 2.1.41 Network Entry Zone ............................................................................................................................... 7 45 2.1.42 Network Management ............................................................................................................................ 7 46 2.1.43 Network Service Provider (NSP) ........................................................................................................... 8 47 2.1.44 Nomadic Access ..................................................................................................................................... 8 48 2.1.45 Paging .................................................................................................................................................... 8 49 2.1.46 Payload Compression ............................................................................................................................ 8 50 2.1.47 Peer-to-Peer Service .............................................................................................................................. 8 51 2.1.48 Point of Attachment Address (PoA) ....................................................................................................... 8 52 2.1.49 Power Management ............................................................................................................................... 8 53 2.1.50 QoS Enforcement and Admission Control ............................................................................................. 9 54


Page - iii


2.1.51 Radio Resource Management (RRM) .................................................................................................... 9 1 2.1.52 Reattachment ......................................................................................................................................... 9 2 2.1.53 Reattachment Zone ................................................................................................................................ 9 3 2.1.54 Reference Point ...................................................................................................................................... 9 4 2.1.55 Roaming ................................................................................................................................................. 9 5 2.1.56 Roaming Agreement Preference List (RAPL) ...................................................................................... 10 6 2.1.57 Root Channel Plan ............................................................................................................................... 10 7 2.1.58 R6-Flex ................................................................................................................................................ 10 8 2.1.59 Service Level Agreement (SLA) ........................................................................................................... 10 9 2.1.60 Session Continuity ............................................................................................................................... 10 10 2.1.61 Session Management............................................................................................................................ 10 11 2.1.62 Simple Ethernet .................................................................................................................................... 10 12 2.1.63 Simple IP .............................................................................................................................................. 10 13 2.1.64 SLA Management ................................................................................................................................. 10 14 2.1.65 Stationary Access ................................................................................................................................. 10 15 2.1.66 MS IP Address Management ................................................................................................................ 11 16 2.1.67 Subscriber Station ................................................................................................................................ 11 17 2.1.68 Tunneling ............................................................................................................................................. 11 18 2.1.69 Visited Network Service Provider (V-NSP) ......................................................................................... 11 19 2.1.70 WiMAX® session .................................................................................................................................. 11 20

2.2 CONVENTIONS .............................................................................................................................................. 11 21 2.3 ABBREVIATIONS/ACRONYMS ....................................................................................................................... 11 22

3. REFERENCES .................................................................................................................................................. 17 23

4. IDENTIFIERS ................................................................................................................................................... 22 24

4.1 IDENTIFIERS USED IN STAGE-2 DOCUMENT .................................................................................................. 22 25 4.1.1 Introduction ......................................................................................................................................... 22 26 4.1.2 List of Identifiers .................................................................................................................................. 22 27

4.2 NETWORK ADDRESSABLE IDENTIFIERS FOR INTER-ASN COMMUNICATIONS ............................................... 24 28

5. TENETS FOR WIMAX® NETWORK SYSTEMS ARCHITECTURE ....................................................... 26 29

5.1 GENERAL ...................................................................................................................................................... 26 30 5.2 SERVICES AND APPLICATIONS ...................................................................................................................... 27 31 5.3 SECURITY ..................................................................................................................................................... 27 32 5.4 MOBILITY AND HANDOVERS ........................................................................................................................ 28 33 5.5 QUALITY OF SERVICE ................................................................................................................................... 28 34 5.6 SCALABILITY, EXTENSIBILITY, COVERAGE AND OPERATOR SELECTION ...................................................... 29 35 5.7 INTERWORKING AND ROAMING .................................................................................................................... 29 36 5.8 MANAGEABILITY .......................................................................................................................................... 29 37 5.9 PERFORMANCE ............................................................................................................................................. 29 38 5.10 MULTI-VENDOR INTEROPERABILITY ............................................................................................................. 29 39 5.11 CONVERGENCE SUBLAYERS (CS) ................................................................................................................. 30 40

6. NETWORK REFERENCE MODEL .............................................................................................................. 31 41

6.1 OVERVIEW .................................................................................................................................................... 31 42 6.2 REFERENCE POINTS ...................................................................................................................................... 32 43

6.2.1 Reference Point R1 .............................................................................................................................. 32 44 6.2.2 Reference Point R2 .............................................................................................................................. 32 45 6.2.3 Reference Point R3 .............................................................................................................................. 33 46 6.2.4 Reference Point R4 .............................................................................................................................. 33 47 6.2.5 Reference Point R5 .............................................................................................................................. 33 48 6.2.6 Reference Point R6 .............................................................................................................................. 33 49 6.2.7 Reference Point R7 .............................................................................................................................. 33 50 6.2.8 Reference Point R8 .............................................................................................................................. 33 51

6.3 ASN REFERENCE MODEL ............................................................................................................................. 33 52


Page - iv


6.3.1 ASN Definition ..................................................................................................................................... 33 1 6.3.2 BS Definition ........................................................................................................................................ 34 2 6.3.3 ASN Gateway Definition ...................................................................................................................... 34 3 6.3.4 Functional Decomposition of ASN Architecture .................................................................................. 34 4

6.4 CORE TO ACCESS NETWORK INTERNETWORKING RELATIONSHIPS ............................................................... 36 5 6.4.1 NAP Sharing ........................................................................................................................................ 37 6 6.4.2 Roaming with HA located in the visited NSP ....................................................................................... 38 7 6.4.3 Roaming with HA located in the home NSP ........................................................................................ 39 8 6.4.4 Stationary Network .............................................................................................................................. 40 9 6.4.5 Client MIP6 network with service connectivity on the CoA as well as on the HoA ............................. 41 10 6.4.6 Simple IP Networks Scenarios ............................................................................................................. 41 11 6.4.7 Simple Ethernet Networks .................................................................................................................... 47 12 6.4.8 MIP-based Ethernet ............................................................................................................................. 49 13 6.4.9 Co-existence of Simple Ethernet and MIP-based Ethernet services with IP services .......................... 50 14 6.4.10 Switched Ethernet WiMAX access network scenario ........................................................................... 51 15 6.4.11 Proxy MIP6 network with service connectivity on the HoA ................................................................. 51 16

6.5 CSN REFERENCE MODEL ............................................................................................................................. 53 17

7. FUNCTIONAL DESIGN AND DECOMPOSITION ..................................................................................... 54 18

7.1 NETWORK ENTRY DISCOVERY AND SELECTION/RE-SELECTION ................................................................... 54 19 7.1.1 Functional Requirements ..................................................................................................................... 54 20 7.1.2 Use Case Scenarios ............................................................................................................................. 54 21 7.1.3 NAP, NSP Domains ............................................................................................................................. 55 22 7.1.4 NAP, NSP Discovery and Selection ..................................................................................................... 56 23

7.2 IP ADDRESSING ............................................................................................................................................ 58 24 7.2.1 IPv4 address Management ................................................................................................................... 58 25 7.2.2 IPv6 ...................................................................................................................................................... 64 26

7.3 AAA FRAMEWORK ....................................................................................................................................... 70 27 7.3.1 Functional Requirements ..................................................................................................................... 70 28 7.3.2 Reference Point Security ...................................................................................................................... 71 29 7.3.3 Functional Decomposition ................................................................................................................... 72 30 7.3.4 RADIUS Reference Protocol Stack ...................................................................................................... 75 31 7.3.5 Diameter Reference Protocol Stack ..................................................................................................... 75 32 7.3.6 RADIUS-Diameter Coexistence ........................................................................................................... 76 33 7.3.7 Routing of AAA messages .................................................................................................................... 76 34 7.3.8 AAA Security ........................................................................................................................................ 76 35 7.3.9 Authentication and Authorization Protocols ........................................................................................ 76 36 7.3.10 Authentication and Authorization Procedures ..................................................................................... 79 37 7.3.11 Certification Version Signaling (CVS) ................................................................................................. 81 38 7.3.12 Co-existence of Fixed/Nomadic Services with Mobility Services ........................................................ 85 39 7.3.13 AAA Framework profile for Ethernet Services .................................................................................... 87 40

7.4 ASN SECURITY ARCHITECTURE ................................................................................................................... 87 41 7.4.1 Architectural Assumptions ................................................................................................................... 89 42 7.4.2 Authenticator Domain and Mobility Domain ...................................................................................... 89 43 7.4.3 Re-Authentication Procedure............................................................................................................... 91 44 7.4.4 Authentication Relay Protocol ............................................................................................................. 91 45 7.4.5 Context Transfer Protocol ................................................................................................................... 92 46

7.5 ACCOUNTING................................................................................................................................................ 95 47 7.5.1 Accounting Architecture ...................................................................................................................... 95 48 7.5.2 Accounting Protocols ........................................................................................................................... 96 49 7.5.3 Offline Accounting ............................................................................................................................... 96 50 7.5.4 QoS-based Accounting ......................................................................................................................... 97 51 7.5.5 Online Accounting (Prepaid) ............................................................................................................... 98 52 7.5.6 Hot-Lining.......................................................................................................................................... 100 53 7.5.7 Accounting Extensions for Ethernet Services .................................................................................... 103 54

7.6 QOS ............................................................................................................................................................ 103 55


Page - v


7.6.1 Introduction and Scope ...................................................................................................................... 103 1 7.6.2 QoS Functional Elements .................................................................................................................. 104 2 7.6.3 Triggers ............................................................................................................................................. 106 3 7.6.4 Messages ............................................................................................................................................ 107 4 7.6.5 QoS-Related Message Flow Examples .............................................................................................. 108 5 7.6.6 IP Differentiated Services .................................................................................................................. 116 6 7.6.7 QoS Profile in the MS ........................................................................................................................ 116 7 7.6.8 Priorization for Ethernet Services ..................................................................................................... 116 8 7.6.9 VLAN Tag Processing for Ethernet Services ..................................................................................... 116 9

7.7 ASN ANCHORED MOBILITY MANAGEMENT ............................................................................................... 117 10 7.7.1 Scope .................................................................................................................................................. 117 11 7.7.2 Functional Requirements for ASN Anchored Mobility Management ................................................. 117 12 7.7.3 HO Function ...................................................................................................................................... 131 13 7.7.4 Data Path Function ........................................................................................................................... 133 14 7.7.5 Context Delivery Function ................................................................................................................. 144 15 7.7.6 Cooperation between the Functions .................................................................................................. 145 16 7.7.7 Reattachment for Fixed/Nomadic Access .......................................................................................... 154 17

7.8 CSN ANCHORED MOBILITY MANAGEMENT ............................................................................................... 155 18 7.8.1 Scope and Requirements for CSN Anchored Mobility (MIP4) Management ..................................... 155 19 7.8.2 R3 Mobility Management with CMIP6 .............................................................................................. 180 20 7.8.3 MIP-based Ethernet Services over R3 ............................................................................................... 192 21 7.8.4 R3 mobility management with PMIP6 ............................................................................................... 197 22

7.9 RADIO RESOURCE MANAGEMENT .............................................................................................................. 205 23 7.9.1 Functional Requirements ................................................................................................................... 205 24 7.9.2 Functional Decomposition ................................................................................................................. 206 25 7.9.3 Primitives ........................................................................................................................................... 208 26 7.9.4 Procedures ......................................................................................................................................... 209 27 7.9.5 Power Management and Interference Control .................................................................................. 212 28

7.10 PAGING AND IDLE-MODE MS OPERATION .................................................................................................. 212 29 7.10.1 Functional requirements .................................................................................................................... 212 30 7.10.2 Functional Decomposition ................................................................................................................. 213 31 7.10.3 Paging and Idle-Mode MS Operation Procedures ............................................................................ 215 32

7.11 DATA PATH ................................................................................................................................................ 225 33 7.11.1 Transport of user payload over R1 .................................................................................................... 225 34 7.11.2 Transport Architecture for IP services .............................................................................................. 226 35 7.11.3 Transport Architecture for Ethernet Services .................................................................................... 227 36 7.11.4 Tunneling within the ASN .................................................................................................................. 229 37 7.11.5 Tunneling over R3 .............................................................................................................................. 231 38 7.11.6 Transport of payload over R5 ............................................................................................................ 231 39

7.12 VOIP SERVICES .......................................................................................................................................... 231 40 7.12.1 Emergency Service ............................................................................................................................. 232 41

7.13 SIMPLE IP MANAGEMENT ........................................................................................................................... 232 42 7.13.1 Simple IPv4 Functional Requirements ............................................................................................... 233 43 7.13.2 Simple IPv6 Management .................................................................................................................. 233 44

7.14 EMERGENCY TELECOMMUNICATIONS SERVICE (ETS) SUPPORT ................................................................ 236 45 7.14.1 Potential Congestion Points in the WiMAX Network ........................................................................ 236 46 7.14.2 ETS subscription types ....................................................................................................................... 236 47 7.14.3 Priority Triggers in ETS Support ....................................................................................................... 237 48 7.14.4 Priority Handling for ETS Support .................................................................................................... 237 49

7.15 ASN GW SELECTION AND LOAD BALANCING ............................................................................................ 238 50 7.15.1 General .............................................................................................................................................. 238 51 7.15.2 ASN GW Selection and Load balancing ............................................................................................ 238 52

53 54


Page - vi


TABLE OF FIGURES 1

FIGURE 6-1 - NETWORK REFERENCE MODEL 2 ............................................................................................................... 32FIGURE 6-2 - ASN REFERENCE MODEL CONTAINING MULTIPLE ASN-GWS 3 ................................................................ 34FIGURE 6-3 - FUNCTIONAL VIEW OF ASN 4 .................................................................................................................... 35FIGURE 6-4 - MULTIPLE ASN TO MULTIPLE CSN CONNECTIVITY 5 ............................................................................... 37FIGURE 6-5 - ROAMING MODEL WITH HA IN VISITED NSP 6 ........................................................................................... 38FIGURE 6-6 - ROAMING MODEL WITH HA IN HOME NSP 7 .............................................................................................. 39FIGURE 6-7 - STATIONARY NETWORK MODEL 8 ............................................................................................................... 40FIGURE 6-8 - MOBILE IPV6 WITH SERVICE OVER COA AND HOA 9 ................................................................................. 41FIGURE 6-9 - SIMPLE IP COMBINED ASN AND CSN STANDALONE 10 ............................................................................... 42FIGURE 6-10 - SIMPLE IP COMBINED ASN AND CSN, ROAMING, ANCHORED AT V-CSN 11 ............................................. 43FIGURE 6-11 - SIMPLE IP COMBINED ASN AND CSN, ROAMING, ANCHORED AT H-CSN 12 ............................................. 44FIGURE 6-12 - SIMPLE IP SPLIT ASN AND CSN, NONE ROAMING 13 ................................................................................. 45FIGURE 6-13 - SIMPLE IP SPLIT ASN AND CSN, ROAMING, ANCHORED AT V-CSN 14 ...................................................... 46FIGURE 6-14 - SIMPLE IP SPLIT ASN AND CSN, ROAMING, ANCHORED AT H-CSN 15 ...................................................... 47FIGURE 6-15 - SIMPLE ETHERNET – COMBINED ASN-CSN, NO ROAMING 16 .................................................................. 48FIGURE 6-16 - SIMPLE ETHERNET – SPLIT ASN-CSN, WITHOUT ROAMING 17 ................................................................. 48FIGURE 6-17 - SIMPLE ETHERNET – COMBINED ASN-CSN WITH ROAMING 18 ................................................................. 49FIGURE 6-18 - COEXISTENCE OF IP SERVICES AND ETH SERVICES 19 .............................................................................. 50FIGURE 6-19 - SWITCHED ETHERNET ACCESS NETWORK 20 .............................................................................................. 51FIGURE 6-20 - PROXY MOBILE IPV6 THROUGH V-CSN WITH SERVICE OVER HOA 21 ...................................................... 52FIGURE 6-21 - PROXY MOBILE IPV6 THROUGH H-CSN WITH SERVICE OVER HOA 22 ...................................................... 52FIGURE 7-1 - COVERAGE AREA WITH OVERLAPPING ASNS 23 ......................................................................................... 56FIGURE 7-2 - DEPLOYMENT EXAMPLE WITH NAP SHARING 24 ......................................................................................... 58FIGURE 7-3 - FUNCTIONAL DECOMPOSITION FOR POA FROM VISITED NSP 25 ................................................................. 60FIGURE 7-4 - FUNCTIONAL DECOMPOSITION FOR POA FROM HOME NSP 26 .................................................................... 61FIGURE 7-5 - IP CONFIGURATION PHASE WITH DHCP RELAY AND DHCP SERVER 27 ..................................................... 62FIGURE 7-6 - IP CONFIGURATION PHASE WITH DHCP PROXY IN ASN 28 ......................................................................... 63FIGURE 7-7 - IPV6 LINK MODEL 29 .................................................................................................................................... 65FIGURE 7-8 - IPV6 ADDRESS CONFIGURATION 30 .............................................................................................................. 66FIGURE 7-9 - STATEFUL MS IPV6 ADDRESS MANAGEMENT 31 ........................................................................................ 68FIGURE 7-10 - GENERIC NON-ROAMING AAA FRAMEWORK 32 ........................................................................................ 72FIGURE 7-11 - GREENFIELD NON-ROAMING AAA FRAMEWORK 33 .................................................................................. 73FIGURE 7-12 - NON AAA COMPLIANT INCUMBENT NON-ROAMING AAA FRAMEWORK 34 ............................................. 73FIGURE 7-13 - GENERIC ROAMING AAA FRAMEWORK 35 ................................................................................................ 73FIGURE 7-14 - GREENFIELD ROAMING AAA FRAMEWORK 36 .......................................................................................... 74FIGURE 7-15 - NON AAA COMPLAINT INCUMBENT ROAMING AAA FRAMEWORK 37 ...................................................... 74FIGURE 7-16 - RADIUS REFERENCE PROTOCOL STACK 38 .............................................................................................. 75FIGURE 7-17 - DIAMETER REFERENCE PROTOCOL STACK 39 ............................................................................................ 75FIGURE 7-18 - PKMV2 USER AUTHENTICATION PROTOCOLS 40 ....................................................................................... 77FIGURE 7-19 - PKMV2 PROCEDURES 41 ........................................................................................................................... 79FIGURE 7-20 - CVS PROCEDURES 42 ................................................................................................................................ 82FIGURE 7-21 - AAA SEVER DECISION CVS PROCEDURES 43 ............................................................................................ 83FIGURE 7-22 - ACCESS SERVICES CO-EXISTENCE NEGOTIATIONS AND SELECTION FLOW 44 ............................................ 86FIGURE 7-23 - INTEGRATED DEPLOYMENT MODEL 45 ...................................................................................................... 87FIGURE 7-24 - STANDALONE DEPLOYMENT MODEL 46 ..................................................................................................... 88FIGURE 7-25 - AUTHENTICATION RELAY INSIDE THE ASN 47 .......................................................................................... 88FIGURE 7-26 - AK TRANSFER INSIDE THE ASN 48 ............................................................................................................ 88FIGURE 7-27 - SINGLE VERSUS MULTIPLE BS PER AUTHENTICATOR 49 ........................................................................... 89FIGURE 7-28 - MOBILITY AND AUTHENTICATOR DOMAINS – STANDALONE MODEL 50 .................................................... 90FIGURE 7-29 - MOBILITY AND AUTHENTICATOR DOMAINS – INTEGRATED MODEL 51 ..................................................... 91FIGURE 7-30 - AUTHENTICATION RELAY PROTOCOL 52 .................................................................................................... 92FIGURE 7-31 - CONTEXT_RPT TRIGGERED BY MOB_HO-IND 53 ..................................................................................... 93FIGURE 7-32 - CONTEXT_RPT TRIGGERED BY RNG-REQ 54 ............................................................................................. 93FIGURE 7-33 - CONTEXT_RPT TRIGGERED BY MOB_MSHO-REQ 55 .............................................................................. 94


Page - vii


FIGURE 7-34 - CONTEXT_RPT TRIGGERED BY MOB_HO-IND 1 ..................................................................................... 94FIGURE 7-35 - ACCOUNTING ARCHITECTURE 2 ............................................................................................................... 95FIGURE 7-36 - HOT-LINING OPERATION 3 ..................................................................................................................... 102FIGURE 7-37 - QOS FUNCTIONAL ELEMENTS 4 ............................................................................................................. 105FIGURE 7-38 - PRE-PROVISIONED SERVICE FLOW CREATION 5 ..................................................................................... 108FIGURE 7-39 - UPDATE OF PRE-PROVISIONED SERVICE FLOW 6 ................................................................................... 109FIGURE 7-40 - SERVICE FLOW CREATION BY ASN 7 ..................................................................................................... 110FIGURE 7-41 - SERVICE FLOW DELETION BY ASN 8 ..................................................................................................... 111FIGURE 7-42 - SERVICE FLOW MODIFICATION BY ASN 9 ............................................................................................. 112FIGURE 7-43 - SERVICE FLOW CREATION BY MS 10 ....................................................................................................... 113FIGURE 7-44 - SERVICE FLOW DELETION BY MS 11 ....................................................................................................... 114FIGURE 7-45 - SERVICE FLOW MODIFICATION TRIGGERED BY MS 12 ............................................................................. 115FIGURE 7-46 - OVERALL REFERENCE FOR ASN MOBILITY FUNCTIONS 13 ..................................................................... 119FIGURE 7-47 - DATA PATH GRANULARITY 14 ................................................................................................................. 121FIGURE 7-48 - OPTIONAL CLASSIFICATION OPERATIONS OF TYPE 1 BEARER 15 ............................................................. 122FIGURE 7-49 - LAYER-2 DATA ANCHORING WITH TYPE-2 DP FUNCTION 16 .................................................................. 123FIGURE 7-50 - DATA TRANSMISSION OVER TYPE-2 BEARER 17 ...................................................................................... 124FIGURE 7-51 - TRANSMISSION BUFFER IN THE SERVING BS UPON MS LEAVING 18 ........................................................ 129FIGURE 7-52 - RECEPTION BUFFER IN THE SERVING BS UPON MS LEAVING 19 .............................................................. 130FIGURE 7-53 - HO FUNCTION NETWORK TRANSACTION 20 ............................................................................................ 131FIGURE 7-54 - DATA PATH FUNCTION NETWORK TRANSACTION 21 ............................................................................... 133FIGURE 7-55 - BOTH PEERS ESTABLISH DATA PATH SIMULTANEOUSLY 22 .................................................................... 139FIGURE 7-56 - TARGET CENTRIC DP CONTROL TRANSACTIONS (WITH PRE-REGISTRATION) DURING HO 23 ................. 141FIGURE 7-57 - TARGET CENTRIC DP CONTROL TRANSACTIONS (WITHOUT PRE-REGISTRATION) DURING HO 24 ........... 142FIGURE 7-58 - TYPICAL ANCHOR CENTRIC DP CONTROL TRANSACTIONS DURING HO 25 ............................................. 143FIGURE 7-59 - COOPERATION BETWEEN THE FUNCTIONS (EXAMPLE) 26 ........................................................................ 147FIGURE 7-60 - COOPERATION BETWEEN THE FUNCTIONS (EXAMPLE2) 27 ...................................................................... 147FIGURE 7-61 - ANCHOR DATA PATH FUNCTION BUFFERING WITH SDU SEQUENCE NUMBERING 28 .............................. 149FIGURE 7-62 - ANCHOR DATA PATH FUNCTION BI-CAST WITH SDU SEQUENCE NUMBERING 29 .................................. 150FIGURE 7-63 - SERVING DATA PATH FUNCTION BI-CAST TO TARGET 30 ........................................................................ 151FIGURE 7-64 - DATA RETRIEVAL INTO ANCHORED BUFFER AND DATA FORWARDING TO TARGET 31 ............................ 152FIGURE 7-65 - DATA PATH ANCHOR BUFFERING WITH SLIDING WINDOW FORWARDING 32 .......................................... 153FIGURE 7-66 - REATTACHMENT PROCEDURE FOR A FIXED OR NOMADIC MS 33 ............................................................. 154FIGURE 7-67 - R3 MOBILITY SCOPE 34 ........................................................................................................................... 156FIGURE 7-68 - PROXY MIP DATA PLANE (EXAMPLE) 35 ................................................................................................ 160FIGURE 7-69 - PROXY MIP CONTROL PLANE 36 ............................................................................................................. 160FIGURE 7-70 - MS MOBILITY EVENT TRIGGERING A NETWORK INITIATED R3 RE-ANCHORING (PMIP) 37 .................... 162FIGURE 7-71 - R3 SESSION RELEASE 38 .......................................................................................................................... 164FIGURE 7-72 - MS WITH MOBILE IP STACK AND MULTIPLE ACCESS OPTIONS 39 ........................................................... 165FIGURE 7-73 - MOBILE IP DATA PLANE (EXAMPLE) 40 .................................................................................................. 165FIGURE 7-74 - MOBILE IP CONTROL PLANE 41 ............................................................................................................... 166FIGURE 7-75 - CONNECTION SETUP 42 ............................................................................................................................ 167FIGURE 7-76 - SESSION RENEWAL, MIP RE-REGISTRATION 43 ....................................................................................... 168FIGURE 7-77 - ASN INITIATED GRACEFUL TERMINATION 44 .......................................................................................... 169FIGURE 7-78 - HA INITIATED GRACEFUL TERMINATION 45 ............................................................................................ 169FIGURE 7-79 - MS LOSS OF CARRIER UNCONVENTIONALLY TERMINATION 46 ............................................................... 170FIGURE 7-80 - R3MM TO INTRA-ASN MOBILITY RELATIONSHIP 47 .............................................................................. 172FIGURE 7-81 - PMIP FUNCTIONAL ELEMENTS 48 ........................................................................................................... 177FIGURE 7-82 - PMIP KEY GENERATION AND TRANSFER – MESSAGE SEQUENCE 49 ....................................................... 178FIGURE 7-83 - CMIP6 DATA PLANE WITH TUNNELING 50 .............................................................................................. 182FIGURE 7-84 - CMIP6 DATA PLANE WITH RO 51 ........................................................................................................... 182FIGURE 7-85 - CMIP6 CONTROL PLANE 52 ..................................................................................................................... 182FIGURE 7-86 - CMIP6 CONNECTION SETUP 53 ................................................................................................................ 183FIGURE 7-87 - CMIP6 SESSION RENEWAL, MIP RE-REGISTRATION 54 .......................................................................... 184FIGURE 7-88 - CMIP6 MOBILITY EVENT TRIGGERING A NETWORK INITIATED R3 RE-ANCHORING (CMIP6) 55 ........... 185FIGURE 7-89 - CMIP6 NETWORK INITIATED GRACEFUL TERMINATION 56 ..................................................................... 187


Page - viii


FIGURE 7-90 - FLOW DIAGRAM FOR DYNAMIC HOME AGENT ASSIGNMENT 1 .............................................................. 188FIGURE 7-91 - BOOTSTRAP OF HOME LINK PREFIX 2 .................................................................................................... 189FIGURE 7-92 - HOME ADDRESS AUTO-CONFIGURATION 3 ............................................................................................ 191FIGURE 7-93 - ETHERNET SERVICES CONTROL PLANE AND DATA PLANE PROTOCOL STACK 4 ....................................... 193FIGURE 7-94 - INITIAL ATTACHMENT IN CASE OF ETHERNET SERVICES 5 ...................................................................... 194FIGURE 7-95 - SESSION TERMINATION BY ANCHOR DPF 6 ........................................................................................... 195FIGURE 7-96 - SESSION TERMINATED BY DPF 7 ............................................................................................................ 195FIGURE 7-97 - SESSION TERMINATION BY HA 8 ............................................................................................................ 196FIGURE 7-98 - PMIP6 CONTROL PLANE 9 ...................................................................................................................... 200FIGURE 7-99 - DATA PLANE WITH PMIP6 10 ................................................................................................................... 201FIGURE 7-100 - PMIP6 CONNECTION SETUP PRINCIPLES 11 ............................................................................................ 202FIGURE 7-101 - PMIP6 MOBILITY HANDOVER PRINCIPLES 12 ......................................................................................... 203FIGURE 7-102 - PMIP6 SESSION TERMINATION PRINCIPLES 13 ........................................................................................ 204FIGURE 7-103 - RRAS RESIDENT IN BS AND RRC RESIDENT IN ASN 14 ........................................................................ 207FIGURE 7-104 - RRA AND RRC COLLOCATED IN BS 15 ................................................................................................. 208FIGURE 7-105 - REQUEST FOR SPARE_CAPACITY_RPT, PER BS 16 ................................................................................... 210FIGURE 7-106 - SPARE_CAPACITY_RPT, PER BS (UNSOLICITED OR SOLICITED) 17 .......................................................... 210FIGURE 7-107 - PHY REPORT (SOLICITED) 18 ................................................................................................................ 211FIGURE 7-108 - NEIGHBOR BS RADIO RESOURCE STATUS UPDATE PROCEDURE 19 ....................................................... 212FIGURE 7-109 - PAGING NETWORK REFERENCE MODEL 20 ............................................................................................ 214FIGURE 7-110 - GENERIC DEPICTION OF FUNCTIONAL ENTITIES PRIOR TO MS ENTERING IDLE MODE 21 ...................... 215FIGURE 7-111 - GENERIC DEPICTION OF FUNCTIONAL ENTITIES AFTER MS ENTERS IDLE MODE 22 .............................. 216FIGURE 7-112 - PAGING GENERATED FOR MS BY INCOMING PACKETS FOR MS IN IDLE MODE 23 ................................. 218FIGURE 7-113 - MS EXITING IDLE MODE 24 ................................................................................................................... 220FIGURE 7-114 - SECURE LOCATION UPDATE 25 .............................................................................................................. 222FIGURE 7-115 - MS ENTERING IDLE MODE 26 ................................................................................................................ 224FIGURE 7-116 - PROTOCOL LAYER ARCHITECTURE FOR IP SERVICE OVER IP-CS 27 ...................................................... 226FIGURE 7-117 - PROTOCOL LAYER ARCHITECTURE FOR IP SERVICES OVER IPOETH-CS 28 .......................................... 227FIGURE 7-118 - PROTOCOL LAYER ARCHITECTURE FOR ETH-CS 29 .............................................................................. 228FIGURE 7-119 - FCS SUPPRESSION OVER R1 30 .............................................................................................................. 229FIGURE 7-120 - GRE ENCAPSULATION 31 ....................................................................................................................... 230FIGURE 7-121 - GRE ENCAPSULATION FOR IP CS 32 ...................................................................................................... 230FIGURE 7-122 - HIGH-LEVEL VIEW OF EMERGENCY SERVICE ARCHITECTURE 33 .......................................................... 232FIGURE 7-123 - SIMPLE IPV6 DATA PLANE PROTOCOL STACK 34 .................................................................................... 234FIGURE 7-124 - CONNECTION SETUP FOR SIMPLE IPV6 SERVICE 35 ................................................................................. 234

36


Page - ix


LIST OF TABLES 1

TABLE 6-1 - INTEROPERABILITY REFERENCE POINTS 2 ................................................................................................... 35TABLE 7-1 - CREDENTIAL TYPES FOR USER AND DEVICE AUTHENTICATION 3 ............................................................... 77TABLE 7-2 - R3MM MOBILITY MANAGEMENT PRIMITIVES “FOR INFORMATION ONLY, THE BINDING FACTS ARE 4

DEFINED IN THE STAGE3 SPECIFICATION” .......................................................................................................... 173 5 TABLE 7-3 - R3MM COEXISTENCE SCENARIOS 6 ........................................................................................................... 176TABLE 7-4 - PRIMITIVES FOR RRM 7 ............................................................................................................................ 209TABLE 7-5 - PRIMITIVES FOR PAGING CONTROL AND LOCATION MANAGEMENT “FOR INFORMATION ONLY, THE 8

BINDING FACTS ARE DEFINED IN THE STAGE3 SPECIFICATION” .......................................................................... 216 9 TABLE 7-6 - REUSE OF HO PRIMITIVES FOR PAGING OPERATION 10 ............................................................................... 217TABLE 7-7 - SUBSCRIPTION TYPES FOR ETS 11 ............................................................................................................... 236

12

13


Page - 1


1. Introduction and Scope 1 This d ocument d escribes t he ar chitecture r eference model, r eference p oints a nd p rotocols an d p rocedures for 2 different end-to-end architecture aspects of WiMAX Forum® Network Architecture. The framework is in response 3 to WiMAX Forum Network Architecture Stage 1 requirements document. 4


Page - 2


2. Abbreviations/Acronyms, Definitions, and Conventions 1

2.1 Definitions 2

2.1.1 AAA 3 AAA r efers t o a framework, ba sed on I ETF pr otocols ( RADIUS or D iameter), t hat s pecifies t he pr otocols a nd 4 procedures for authentication, authorization, and accounting associated with the user, MS, and subscribed services 5 across different access technologies. For example, AAA includes mechanisms for secure exchange and distribution 6 of authentication credentials and session keys for data encryption. 7

Location: ASN and CSN 8

2.1.2 Access Service Network (ASN) 9 Access Service Network (ASN) is defined as a complete set of network functions needed to provide radio access to a 10 WiMAX® subscriber. The ASN provides the following mandatory functions: 11

o WiMAX Layer-2 (L2) connectivity with WiMAX MS, 12

o Transfer o f A AA messages t o W iMAX s ubscriber’s H ome N etwork S ervice P rovider (H-13 NSP) for authentication, authorization and session accounting for subscriber sessions, 14

o Network discovery and selection of the WiMAX subscriber’s preferred NSP, 15

o Relay functionality for e stablishing L ayer-3 ( L3) co nnectivity with a W iMAX M S ( i.e. I P 16 address allocation) 17

o Radio Resource Management. 18

In addition to the above mandatory functions, for a portable and mobile environment, an ASN SHALL support the 19 following functions: 20

o ASN anchored mobility, 21

o CSN anchored mobility, 22

o Paging, 23

o ASN-CSN tunneling. 24

ASN comprises network elements such as one or more Base Station(s), and one or more ASN Gateway(s). An ASN 25 MAY be shared by more than one Connectivity Service Networks (CSN). 26

2.1.3 Accounting Agent 27 The Accounting Agent is defined as the functional entity which collects the related accounting information, such as 28 the unsent downlink volume information to the MS and the airlink record information, etc. 29

Location: ASN 30

2.1.4 Admission Control 31 Admission Control is the a bility to admit or a bility t o c ontrol admission of a user to a network based on user’s 32 service profile and network performance parameters (for example, load and average delay). If a user requests access 33 to network services but the incremental resources required to provide the grade of service specified in the user’s 34 service p rofile ar e n ot av ailable, t he A dmission Control f unction r ejects t he u ser’s access r equest. N ote t hat 35 Admission Control is implemented to ensure service quality and is different from authentication and authorization, 36 which are also used to admit or deny network access. 37

Location: ASN and CSN 38

2.1.5 Application Service Provider (ASP) 39 Application Service Provider (ASP) is a business entity that provides applications or services via V-NSP or H-NSP. 40


Page - 3


2.1.6 AR 1 Access Router. 2

2.1.7 ASN Anchored Mobility 3 ASN Anchored Mobility refers to the set of procedures associated with the movement (handover) of an MS between 4 two Base Stations (referred to in the IEEE Std 802.16 l iterature as Serving and Target BS), where the Target BS 5 may belong to the same ASN or a different one, without changing the traffic anchor point for the MS in the serving 6 (anchor) ASN. The associated procedures involve transferring the context o f al l service flows together with o ther 7 context from t he previous B S to th e new B S while attempting to ensure minimal d elay a nd d ata lo ss d uring the 8 transition. ASN Anchored Mobility is mobility within the area of one or more ASNs without Anchor DP Function 9 relocation, i.e. without R3 Mobility. This includes intra-ASN and inter-ASN MM as long as the “ASN R3 reference 10 anchor point” in the NAP, and hence the FA (or the MAG, respectively),, does not change for MIPV4. 11

Entities: MS and ASN 12

2.1.8 ASN Mobility 13 Same as ASN Anchored Mobility. 14

2.1.9 Authenticator 15 Authenticator functionality is defined as per standard EAP 3-party model. An authenticator is an entity at one end of 16 a poi nt-to-point li nk t hat facilitates a uthentication o f s upplicant ( MS) a ttached to th e o ther e nd o f t hat l ink. I t 17 enforces au thentication b efore al lowing acce ss t o s ervices t hat ar e acce ssible t o WiMAX® subscribers. T he 18 Authenticator a lso in corporates AAA c lient functionality t hat e nables it to c ommunicate with t he AAA b ackend 19 infrastructure (A AA-based A uthentication Server) which provides t he A uthenticator with a uthentication s ervices 20 over AAA protocols. The Authenticator is always collocated with the Key Distributor and MAY be collocated with 21 the Authentication Relay and Key Receiver functions as defined in Part 2 Section 7.4 – ASN Security Architecture. 22

2.1.10 Base Station 23 See Section 6.3.2. 24

2.1.11 Channel Plan 25 A Channel Plan is used by the device to speed up NAP discover process. I t contains physical information such as 26 channel bandwidth, center frequency, and PHY profile. 27

2.1.12 Connectivity Service Network (CSN) 28 Connectivity Service Network (CSN) is defined as a set of network functions that provide IP connectivity services to 29 the WiMAX subscriber(s). A CSN MAY provide the following functions: 30

o MS IP address and endpoint parameter allocation for user sessions 31

o Internet access 32

o AAA proxy or server 33

o Policy and Admission Control based on user subscription profiles 34

o ASN-CSN tunneling support 35

o WiMAX subscriber billing and inter-operator settlement 36

o Inter-CSN tunneling for roaming 37

o Inter-ASN mobility 38

o WiMAX services s uch as l ocation b ased s ervices, co nnectivity for p eer-to-peer s ervices, 39 provisioning, a uthorization a nd/or c onnectivity to I P multimedia services a nd facilities to 40 support lawful i ntercept s ervices such as t hose compliant with Communications A ssistance 41 Law Enforcement Act (CALEA) procedures. 42

CSN MAY comprise network elements such as routers, AAA proxy/servers, user databases, Interworking gateway 43 MSs. A CSN MAY be deployed as part of a Greenfield WiMAX NSP or as part of an incumbent WiMAX NSP. 44


Page - 4


2.1.13 Contractual Agreement Preference List (CAPL) 1 A list consisting of Network Access Providers preferred to be connected to the home network directly. 2

2.1.14 CR 3 Core Router. 4

2.1.15 CSN Anchored Mobility 5 CSN Anchored mobility refers to a set o f procedures f or changing the t raffic anchor p oint for the MS from one 6 anchor point to another one in the ASN without changing the CSN anchor. CSN anchored mobility is independent to 7 the .16e handover. 8

Entities: MS, ASN, CSN 9

2.1.16 E-LAN Service 10 The E thernet L AN S ervice ( E-LAN S ervice) p rovides m ultipoint E thernet c onnectivity be tween t wo or more 11 SSs/MSs possibly to an ASP providing Ethernet Connectivity Services. Forwarding of Ethernet frames among end-12 stations in a particular E-LAN service is performed based on bridging. 13

2.1.17 E-Line Service 14 The Ethernet Line Service (E-Line Service) provides a p oint-to-point connectivity for transport of Ethernet frames 15 between t wo S Ss/MSs o f t he Mo bile W iMAX® network or be tween a S S/MS a nd a n ASP pr oviding E thernet 16 services. 17

Any Ethernet service that is based on a Point-to-Point Ethernet Virtual Connection is designated as an Ethernet Line 18 Service (E-Line) type. An E-Line Service type can be used to create a broad range of point-to-point services. [82] 19

2.1.18 E-Tree Service 20 The E thernet T ree s ervice ( E-Tree S ervice) pr ovides a rooted m ultipoint E thernet c onnectivity b etween t he 21 centralized SS/MS or an ASP providing Ethernet services acting as a r oot to two or more SSs/MSs designated as 22 leaves. An E -Tree S ervice t ype may s upport t wo o r more r oots which ca n co mmunicate with eac h o ther. T he 23 Ethernet Traffic is allowed to flow only from the leaf to the root and never being transmitted to other leaves. [86] 24

Note: P reventing le af to le af c onnectivity may b reak I Pv6 o peration. The d efinition o f E -Tree i s pr ovided f or 25 information only. E-Tree like behavior may be realized by the public access mode of the Ethernet service. 26

2.1.19 Ethernet Support 27 WiMAX Ethernet support re fers to a t ransport that carries Ethernet frames according to IEEE802.3, IEEE802.1D 28 and IEEE802.1Q amended by IEEE802.1ad across the WiMAX network. Ethernet may be used to encapsulate IPv4 29 or IPv6 packets or other payload and encapsulation of end-user data sessions. Ethernet traffic may be tunneled using 30 MPLS, GRE or other tunneling protocols. 31

Some examples for Ethernet services in WiMAX networks are: 32

o End-to-End E thernet connectivity from the WiMAX SS/MS across the WiMAX network to a n ASP 33 providing Ethernet services (e.g. for connectivity to DSL networks with PPPoE) or across the WiMAX 34 network to a nother W iMAX SS/MS. Depending on whether the t ransparent LAN service i s used b y 35 private network ope rators to extend corporate LANs or is used by I SPs to pr ovide public access t o 36 Internet services to many customers, different operational modes are selected: 37

- Public Access Mode 38 When deploying Ethernet aggregation for public access services, the LAN service usually restricts 39 direct communication between customers’ endpoints and enforces that all Ethernet frames are 40 passed through the ISP head-end to enable accounting and enforcement of security policies by the 41 ISP. From the customer’s perspective the service is looking more like an E-Line service towards 42 the ISP, but from the ISP side, all customers are residing on the same link. 43

- Enterprise LAN Mode 44 When all connected end stations are belonging to the same enterprise and are residing in the same 45 security domain, direct connectivity across the Transparent LAN Service (TLS) from any end 46


Page - 5


station to any other end station is feasible. In this mode the E-LAN service really behaves like a 1 LAN with all stations being reachable from any interface on the same link. 2

o Ethernet support within the ASN segment o nly. I t allows t he t ransport o f E thernet f rames between 3 WiMAX SS/MS and the mobility a nchor (FA, Access Router) i nside the ASN when I PoETH CS i s 4 deployed for providing IP services out of the Mobile WiMAX network. 5

The functional behavior of Ethernet services at the customer edge to the network is described by service attributes. 6 A comprehensive definition and description of the attributes for Ethernet services can be found in [83]. 7

Location: MS, ASN, and CSN 8

2.1.20 Firewall 9 A firewall pr ovides pr otection t o network e lements b y e nforcing a ccess a nd f ilter pol icies us ed t o monitor a nd 10 control t raffic to and from a n etwork. I t can be viewed as a set o f rules and policies that determine which t raffic 11 should be permitted to go through or blocked. One of its main purposes is to detect and prevent Denial of Service 12 (DoS) attacks on a network. 13

Location: ASN, CSN, and possibly the ASP Network's infrastructure 14

2.1.21 Fixed Access 15 Refers to the type of access allowed to a SS that is classified as fixed in the H-AAA. The user device is assumed to 16 be fixed in a single geographic location for the duration of the network subscription. The user device shall be able to 17 connect and disconnect from the network at a specific BS that will be associated with the subscription in the AAA. 18 The user device will typically have a fixed point of a ttachment to the radio access network; only the network can 19 decide to redirect the point of attachment of the user device (see definition of reattachment), for example to improve 20 reliability or for load balancing purposes. 21

2.1.22 Home Network Service Provider (H-NSP) 22 A h ome N SP i s t he o perator o r b usiness e ntity t hat has Service Level Agreements with W iMAX® subscribers, 23 authenticates an d au thorizes subscriber s essions ( in-network o r r oaming s cenarios) an d s ervices t he s ubscriber's 24 account (charging and billing). To support roaming services, a Home NSP MAY have roaming relationships with 25 other NSPs. 26

2.1.23 Integrated ASN 27 Integrated ASN describes implementations where all the ASN functions are located within a s ingle physical device 28 providing R1 on the radio side and R3 on the network side. An Integrated ASN does neither expose the reference 29 point R6 between BS and ASN-GW, nor the reference point R8 between BSs, but may provide the R4 reference 30 point for interconnectivity to adjacent ASNs. 31

2.1.24 Internet Access 32 Internet access refers to a gateway that resides at the edge of NAP or NSP network connecting it to Internet. Apart 33 from t he I P r outing functionality, s uch ga teways M AY include functions such a s V PN, F irewall, N AT, l ayer-4 34 forwarding, and mobile IPv4 home agent. Alternatively, these functions MAY be implemented in network elements 35 that a re e ither i n front o f o r behind t he gateway. C ertain d eployments M AY al so implement functions such as 36 metering and policing as part of Internet Access. 37

2.1.25 Internet-working Function 38 An Internetworking Function ( IWF) or a n I nternetworking U nit ( IWU) i s a network e ntity t hat t ranslates o ne or 39 more c ommunication pr otocols (data and/or c ontrol) from one f orm t o a nother. An I WU en ables integration o r 40 interoperability b etween d ifferent t ypes o r generations of networks a nd/or s ervices. For e xample, a n I WU 41 terminating a WiMAX F orum® Network A rchitecture-specified r eference p oint M AY f acilitate i nteroperability 42 between a Greenfield WiMAX network and an incumbent 3G network. 43

Location: This function resides in the CSN. 44

2.1.26 IP Header Compression 45 Header co mpression i s a function to r educe t he s ize o f t he headers o f t he p ackets an d i ncrease t he o verall 46 communication performance between a pair of communication nodes. 47


Page - 6


Location: MS and ASN 1

2.1.27 IP Support 2 IP Support refers to the capability of the WiMAX® network to transport IPv4 and IPv6 datagrams as end to end 3 managed session between the WiMAX SS/MS and any IP peer across WiMAX network. IP support does not require 4 any additional L2 encapsulation over the air except for 802.16e and MAY be tunneled in WiMAX network using 5 GRE, MPLS, VLAN or other tunneling protocols. 6

2.1.28 IPv4 Support 7 IPv4 support refers to a set of capabilities that enable IPv4 addressing and encapsulation of end-user data sessions. 8 The I Pv4 en capsulation M AY d irectly e ncapsulate a n I Pv4-compatible a pplication protocol r unning o ver I P 9 transports, such as FTP, SIP, SMTP or HTTP. Alternatively, it MAY encapsulate tunneled end-user data as in the 10 cases of Mobile IP, IPsec or GRE. T he end-user IPv4 session MAY in turn be encapsulated within the NAP and 11 NSP networks in an IPv6 tunnel, so long as the IPv6 cladding is removed prior to the delivery of its IPv4 contents. 12 IPv4 S upport doe s n ot g uarantee pe rformance of a ny pa rticular e nd-user I Pv4 f low, o nly that the flow will b e 13 conveyed between any two nodes in the NAP or NSP networks in a manner logically consistent with IPv4. 14

Location: MS, ASN, CSN and ASP Network infrastructure 15

2.1.29 IPv6 Access Router (AR) 16 The IPv6 AR is the first hop router for an IPv6 MS in the ASN. The IPv6 link exists between the MS and the IPv6 17 AR and is established via a combination of the transport connection over the air interface (R1) and the GRE tunnel 18 between the BS and ASN-GW functions when implemented in separate physical entities. 19

2.1.30 IPv6 Support 20 IPv6 support is a set of capabilities enabling IPv6 addressing and encapsulation of end-user data sessions. The IPv6 21 encapsulation MAY directly encapsulate an IPv6-compatible application protocol running over IP transports, such 22 as FTP, SIP, SMTP or HTTP. Alternatively, it MAY encapsulate tunneled end-user data as in the case of GRE. The 23 end-user IPv6 session MAY in turn be encapsulated within the NAP and NSP networks in an IPv4 tunnel, so long as 24 the I Pv4 c ladding i s r emoved pr ior t o t he de livery o f i ts I Pv6 c ontents. I Pv6 support doe s n ot guarantee t he 25 performance of any particular end-user IPv6 flow, only that the flow will be conveyed between any two nodes in the 26 NAP or NSP networks in a manner logically consistent with IPv6. 27

Location: MS, ASN, CSN and ASP Network infrastructure 28

2.1.31 Location-Based Service (LBS) 29 A location-based service (or LBS) is a service provided to a subscriber based on the current geographic location of 30 the WiMAX client MS. 31

Location: CSN or ASP Network and MS 32

2.1.32 Media Gateway 33 A media gateway is an entity that converts media formats in order to provide compatibility between two networks. . 34 For example, a media gateway could terminate bearer channels from a s witched ci rcuit network (e.g., DS0s) and 35 media streams from a p acket network (e.g., RTP streams in an IP network). A media gateway MAY be capable of 36 processing a udio, vi deo a nd T .120 a lone or i n a ny c ombination, a nd M AY be c apable of f ull d uplex media 37 translations. Additionally, a m edia g ateway M AY a lso p lay a udio/video m essages a nd s upport in teractive voice 38 response features, or MAY perform media conferencing. 39

Location: CSN or existing core network in an Interworking scenario 40

2.1.33 MIP based Ethernet 41 Mobile IP is the only protocol specified in Mobile WiMAX for the interface between ASN and CSN. Mobile IP sets 42 up dynamic tunnels between ASN and CSN. MIP based Ethernet refers to an Ethernet service out of a WiMAX 43 access network in which the ASNs enabled for Ethernet connectivity are connected by a dynamic tunneling protocol, 44 i.e. Mobile IP, to the CSN. Dynamic tunneling al lows for nomadic access to Ethernet services across nation-wide 45 WiMAX access networks c onsisting o f hundreds o f ASNs a nd CSNs o r f or d eployments in c omplex network 46 scenarios with many i ndependent N APs a nd N SPs i nvolved i n t he p rovisioning o f E thernet services. D ynamic 47


Page - 7


tunneling allows for the relocation of the anchor of a SS/MS from one ASN to another ASN without interrupting the 1 service, which is the prerequisite for mobility across large networks. 2

2.1.34 Mobility Access 3 Mobility Access refers to one or any combination of the following types of access: Portable Access, Simple mobility 4 Access and Full mobility Access as described in Stage 1 requirements specification [79]. 5

2.1.35 Mobility Access Classifier 6 This refers to the classification of the subscriber at the H-AAA as a f ixed, nomadic or mobile access subscriber. A 7 subscriber may have multiple classifications based on the NAP or V-CSN where a network entry takes place. 8

2.1.36 Mobile Station (MS) 9 Generalized mobile equipment set providing connectivity between subscriber equipment and a base station (BS). 10 The Mobile Station MAY be a host or a CPE type of device that supports multiple hosts. 11

2.1.37 NAP Based Channel Plan 12 A Channel Plan which is a subset of Root Channel Plan and is associated with a NAP. 13

2.1.38 NAS 14 The term NAS refers to the grouping of the following functions in the ASN: 15

• EAP Authenticator 16

• The Prepaid Client 17

• Hot-line Device 18

• AAA client 19

• Accounting Client 20

In addition to the above, the NAS maintains and distributes keys received from the AAA infrastructure to various 21 other functions in the ASN and for that reason may also be labeled Anchor Authenticator. 22

2.1.39 Network Access Provider (NAP) 23 Network Access Provider (NAP) is a b usiness entity that provides WiMAX® radio access infrastructure to one or 24 more WiMAX Network Service Providers (NSPs). A NAP implements this infrastructure using one or more ASNs. 25

2.1.40 Network Discovery and (Re)selection 26 Network Discovery and (Re)selection refers to protocols and procedures where the MS detects the existence of one 27 or more NAPs owned by or affiliated with the subscriber’s home NSP (directly or through a r oaming partner) and 28 selects a NAP based on its local policy to gain access to IP data services. 29


2.1.41 Network Entry Zone 31 For a fixed access subscriber, this is the BS(s) identifier or geographic area information associated with the network 32 subscription. N omadic acces s s ubscriber may b e as sociated with a network e ntry zo ne t hat co uld s pan a l arge 33 geographic area. 34

2.1.42 Network Management 35 Network management r efers to a v ariety o f t ools, ap plications, an d M Ss that as sist human network managers i n 36 monitoring and maintaining networks. The fundamental classes of management operations are typically described as 37 Fault, Configuration, Accounting, Performance and Security (FCAPS). 38

Most network management architectures use the same basic structure and set of relationships. Managed MSs, such 39 as computer systems and other network MSs, run software (typically referred to as an agent) that enables network 40 managers to query information from agents or be notified when they recognize problems (for example, when one or 41 more user-determined thresholds are exceeded). Upon receiving these alerts, management entities are programmed 42


Page - 8


to r eact b y e xecuting o ne, s everal, o r a gr oup o f a ctions, i ncluding o perator no tification, e vent l ogging, s ystem 1 shutdown, and automatic attempts at system repair. 2

Location: The ASN, CSN and ASP infrastructure will nominally have independent network management functions. 3 Mechanisms to query and process the management information bases MAY be centralized or distributed. 4

2.1.43 Network Service Provider (NSP) 5 Network S ervice Provider ( NSP) is a b usiness e ntity th at p rovides I P c onnectivity and W iMAX® services t o 6 WiMAX s ubscribers compliant w ith the S ervice L evel A greement it establishes w ith W iMAX s ubscribers. To 7 provide these services, an NSP establishes contractual agreements with one or more NAPs. Additionally, an NSP 8 MAY also establish roaming agreements with o ther NSPs and contractual agreements with third-party application 9 providers (e.g., ASP or ISPs) for providing WiMAX services to subscribers. 10

From a W iMAX s ubscriber standpoint, an N SP MA Y b e cl assified as H ome N SP ( H-NSP) o r V isited N SP ( V-11 NSP). 12

2.1.44 Nomadic Access 13 Refers to the type of access allowed to an SS that is classified as Nomadic in the H-AAA. The user device shall be 14 able to connect and disconnect from the network at a specific set of BS that will be associated with the subscription 15 in t he AAA. D uring a data service session, the user device will t ypically have a fixed point o f a ttachment to t he 16 radio access network; only the network can decide to redirect the point of attachment (see definition of 17 reattachment) of the user device, for example to improve reliability or for load balancing purposes. If the user device 18 is moved to a different location in the same wireless network resulting in a different point of attachment, then a 19 network entry may be performed, the user device subscription is recognized, the network protocol stack of the user 20 device and host is reset, and a new data service session is established. 21

2.1.45 Paging 22 Paging refers to procedures used by the network to seek an MS in idle mode in the coverage area of a predefined set 23 of Base Station(s) identified by a Paging Group (as per IEEE Std 802.16e). In addition, Paging Update refers to 24 procedures to obtain location update or network entry from an MS in idle mode. Paging procedures are implemented 25 using Paging MAC message exchanges between MS and BS, under the control of a higher-layer paging management 26 functions. 27

Location: ASN and MS 28

2.1.46 Payload Compression 29 Payload compression is a function to reduce the size of datagram payloads and increase the overall communication 30 performance between a p air of communication nodes. Examples of payload compression protocols include the use 31 of [37] over IP transport. 32

Location: T he pa yload c ompression f unction a nd i ts pr otocol SHALL be r unning be tween t wo c ommunicating 33 peers. 34

2.1.47 Peer-to-Peer Service 35 Peer-to-peer or point-to-point services are IP services delivered to MS using a point-to-point IP-connectivity bearer 36 channel. The correspondent node to MS for such services MAY be another MS or a network server. Examples of 37 such services include peer-to-peer file-sharing, VoIP, gaming, etc. 38

Location: MS, CSN, or ASP Network 39

2.1.48 Point of Attachment Address (PoA) 40 A Point of Attachment (PoA) address refers to the IP address, routable in CSN domain that is allocated to MS for 41 the p urpose o f d ata co nnectivity. F or fixed, nomadic, simple I P an d P MIP-based acces s, t he P oA ad dress i s 42 delivered to MS using DHCP. For CMIP4-based mobile SS/MSs, t he PoA address i s d elivered using MIP-based 43 procedures. For MIP4-based access, a P oA address refers to Home Address. For MIP6 based access, a P oA may 44 refer to the CoA or HoA. 45

2.1.49 Power Management 46 There are two aspects of power management: 47


Page - 9


o MS platform power management – This refers to efficient allocation of Sleep and Idle modes to an MS 1 with t he in tention o f maximizing b attery li fe while minimizing d isruption to c ommunication flows 2 between an MS and the network. Sleep and Idle modes are described in the 802.16e specification. 3

o MS transmit power management – This refers to the management of MS transmit power based on one 4 or more factors with the intent to conserve battery resources while not impacting communication flows 5 between an MS and the network. 6


2.1.50 QoS Enforcement and Admission Control 8 QoS enforcement and admission control refers to procedures that ensure QoS in the ASN infrastructure comprising 9 infrastructure p rovided b y more t han o ne Service P rovider o r t hird-party car rier. T hese f unctions i nclude Q oS 10 profile authorization, QoS admission control, Policy Enforcement Point (PEP), Policy Decision Functions (PDF), 11 policing and monitoring, QoS parameter mapping across different QoS domains, etc. These procedures MAY reside 12 within a network or distributed across networks. 13

Location: MS, ASN, CSN, and ASP Network 14

2.1.51 Radio Resource Management (RRM) 15 Radio R esource M anagement r efers t o measurement, exchange, a nd control of r adio r esource-related i ndicators 16 (e.g., current subchannel allocations to service flows) in a wireless network. 17

Measurement refers t o d etermining values o f standardized r adio resource i ndicators t hat measure o r as sist i n 18 estimation of available radio resources. 19

Exchange refers t o pr ocedures a nd pr imitives be tween functional entities used f or r equesting a nd r eporting s uch 20 measurements or e stimations. The r esulting i nformation from e xchange M AY b e made a vailable within t he 21 measuring station (using proprietary procedures and primitives), or, to a remote functional entity (using standardized 22 procedures and primitives). 23

Control refers t o d ecisions made b y t he measuring station o r r emote e ntity t o ad just ( i.e., al locate, r eallocate o r 24 deallocate) radio resources based on the reported measurements, other information, or using proprietary algorithms, 25 and communicating such adjustments to network entities using standardized primitives. Such control MAY be local 26 and remote from the measuring station. 27


2.1.52 Reattachment 29 Reattachment i s the process in which the point of at tachment of a s tationary SS/MS is redirected by the network, 30 from the current serving BS to a new target BS chosen from a limited static set of neighboring BSs. This will use 31 some mobility r elated P HY/MAC features of I EEE S td 802.16e-2005 [ 2] a nd i s t ypically don e t o i mprove t he 32 quality of a connection or for load balancing purposes. Unlike in handover, in reattachment no support/guarantee is 33 provided for the continuity o f the data session or the voice cal l once the SS/MS moves to the air interface of the 34 target BS and the SS/MS is typically expected to re-initiate the data session or the voice call. 35

2.1.53 Reattachment Zone 36 The reattachment zone is the static set of neighboring BSs (this static set is usually configured by the operator for 37 each B S i n t he acces s n etwork p roviding stationary a ccess s ervices) t hat t he acc ess network m ay us e f or 38 reattachments (see definition of reattachments). 39

2.1.54 Reference Point 40 A reference point (RP) is a conceptual link that connects two groups of functions that reside in different functional 41 entities of an ASN, CSN, or MS. It is not necessarily a physical interface. A reference point only becomes a physical 42 interface when the functional entities on either side of it are contained in different physical MSs. 43

2.1.55 Roaming 44 Roaming is the capability of wireless networks via which a wireless subscriber obtains network services using a 45 “visited network” operator’s coverage area. At the most basic level, roaming typically requires the ability to reuse 46 authentication c redentials pr ovided/provisioned by t he hom e ope rator i n v isited n etworks, s uccessful u ser/MS 47


Page - 10


authentication b y the home o perator, and a m echanism for b illing reconciliation and optionally access to services 1 available o ver t he I nternet s ervices. A key b enefit o f r oaming i s t o p rovide a wider co verage a nd acces s t o 2 subscribers of an operator with consolidated/common billing. 3

Location: MS, ASN, and CSN 4

2.1.56 Roaming Agreement Preference List (RAPL) 5 A list consisting of Network Service Providers preferred to be connected when roaming. 6

2.1.57 Root Channel Plan 7 A Channel Plan which contains all Channel Plan Entries. 8

2.1.58 R6-Flex 9 The BS is able to communicate over R6 to different ASN-GWs located within the same ASN. For example, the BS 10 can communicate over R6 to ASN-GW_1 for MS_1 and to ASN-GW_2 for MS_2. 11

2.1.59 Service Level Agreement (SLA) 12 A S ervice L evel Agreement ( SLA), as d efined i n [8] is “a co ntract b etween a n etwork’s p rovider an d u ser o r 13 between network providers that defines the service level which a user will see or an operator can obtain and the cost 14 associated with that level of service”. 15

2.1.60 Session Continuity 16 The user device has a co mmunication session that i s maintained throughout handovers between cel ls, sectors and 17 base stations; its application IP address(es) is(are) maintained. 18

2.1.61 Session Management 19 At a fundamental level, a session refers to link-layer, IP-layer, or, higher layer connectivity established between one 20 or more MS and a network element in order to exchange link-level frames or packets. Additionally, a session MAY 21 have cer tain well-defined p roperties as sociated with i t s uch a s t raffic ch aracteristics ( e.g., traffic t ype, p olicy, 22 encryption), mobility support (e.g., re-authentication, re-keying, routing), and robustness (e.g., state management, 23 persistence). Session management generically refers to the set of procedures implemented in MS and the network 24 that support all such properties associated with an active session. 25

Location: MS and ASN or CSN or ASP Network 26

2.1.62 Simple Ethernet 27 Simple Ethernet refers to an Ethernet service out of a WiMAX® access network in which ASNs enabled for Ethernet 28 connectivity are connected to CSNs supporting Ethernet services. The transport protocol used between ASN and 29 CSN is not specified and is left to the discretion of the involved network operators. 30

The Simple Ethernet network is equivalent to the Simple IP network for IP services. The relocation of the anchor of 31 a SS/MS supporting Ethernet service from one ASN to another ASN without interrupting the service is out of scope 32 for Simple Ethernet. 33

2.1.63 Simple IP 34 Refers to a service in which no MIP-based network elements are used in the WiMAX network. MS/SS is assigned 35 an IP address via DHCP or auto-configuration and is provided IP transport service. The MS/SS retains its IP address 36 as long as the Access Network providing point of attachment for the MS/SS has connectivity to the serving router. 37

2.1.64 SLA Management 38 SLA management refers to procedures that translate a Service Level Agreement into a s et of QoS parameters and 39 their values, which together define the service offered. 40

Location: This function MAY be located between ASN and CSN, CSN and ASP's infrastructure, or between CSNs 41 of two NSPs. 42

2.1.65 Stationary Access 43 Stationary access refers to Fixed Access or Nomadic Access or both. 44


Page - 11


2.1.66 MS IP Address Management 1 IP address assignment is typically done after the MS is authenticated and authorized to the network. The IP address 2 allocated to an MS may be public or private, and may either be a point-of-attachment IP address or an inner-tunnel 3 IP address. For the basic-connectivity IP service, the IP address is assigned by the CSN (incumbent or reference). 4 For IP services accessible over an inner-tunnel, the network that terminates the tunnel allocates the IP address. 5

Location: MS and CSN 6

2.1.67 Subscriber Station 7 Generalized stationary equipment set providing connectivity between subscriber equipment and a base station (BS). 8 The Subscriber Station may be a host or support multiple hosts. 9

2.1.68 Tunneling 10 Tunneling refers to the capability that enables two packet networks to exchange data or packets via intermediate 11 networks, while hiding the protocol details from the intermediate networks. Tunneling is generically implemented 12 by e ncapsulating a n e nd-to-end n etwork p rotocol w ithin packets t hat ar e n atively car ried o ver t he i ntermediate 13 networks. For example, Point-to-Point Tunneling Protocol (PPTP) is a technology that enables organizations to use 14 the Internet to transmit private data across a VPN. It does this by embedding its own network protocol within the 15 TCP/IP packets carried by the Internet. Tunneling is alternately referred to as encapsulation. 16

Location: MS and CSN and/or ASP's infrastructure. 17

2.1.69 Visited Network Service Provider (V-NSP) 18 A visited NSP is defined from a roaming WiMAX® subscriber standpoint. A roaming subscriber uses the visited 19 NSP’s co verage ar ea f or acces s t o W iMAX s ervices. A visited N SP may have r oaming relationship w ith 20 subscriber’s h ome N SP. T he v isited N SP pr ovides A AA t raffic r outing t o h ome N SP. D epending on W iMAX 21 services requested and the roaming agreement between home NSP and visited NSP, the visited NSP MAY provide 22 some/all WiMAX services to roaming WiMAX subscriber or provide data/control traffic routing to home NSP. 23

2.1.70 WiMAX® session 24 A WiMAX session is established when the MS performs a successful initial network entry. The WiMAX session is 25 terminated when network exit procedures are performed. 26

The W iMAX s ession is id entified b y t he AAA-Session-ID. T he AAA -Session-ID i s a ssigned b y t he h AAA 27 performing the authentication procedure that is part of the initial network entry. 28

The AAA -Session-ID is used in a ll A AA tr ansactions c oncerning th at M S. T he W iMAX S ession an d h ence t he 29 AAA-Session ID persists across al l anchor authenticator relocations and i s al so conveyed to al l HAs during MIP 30 authentication procedures. The AAA-Session-ID is also inserted into the accounting stream and is used to correlate 31 accounting records to that WiMAX session. 32

2.2 Conventions 33

The k ey words “MUST”, “ MUST NOT ”, “ REQUIRED”, “ SHALL”, “SHALL NOT ”, “ SHOULD”, “SHOULD 34 NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be i nterpreted as described in 35 [10]. 36

2.3 Abbreviations/Acronyms 37

The f ollowing t able l ists s everal a bbreviations a nd a cronyms used t hroughout WiMAX F orum® Network 38 Architecture Stage 2 and Stage 3 documents. 39

Abbreviation Expansion of Abbreviation

3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2 AA Anchor Authenticator also called Network Authenticator Server (NAS) AAA Authentication, Authorization, and Accounting


Page - 12



AAA Proxy An intermediary for transparently routing and/or processing AAA messages sent between an AAA client and an AAA server

AAA Server Computer system performing AAA services (authentication, authorization, accounting) AAA-V AAA proxy server located within the visited network AASN Anchor ASN. Refers to the ASN that holds the Anchor Data Path Functions for a given MS AC Admission Control ADPF Anchor Data Path Function AF Application Function AK Authorization Key AKA Authentication and Key Agreement AK SN - Derivation from PMK and PMK2 SN AM Authorization Module APC Anchor paging Controller A-PCEF Policy and Charging Enforcement Function in the ASN. See [88] for further details. APCF Anchor paging controller function API Application Program Interface AR Access Router ARQ Automatic Retransmission Request AS Authentication Server ASN Access Service Network ASP Application Service Provider BCE Binding Cache Entry BE Best Effort BRAS Broadband Remote Access Server BS Base Station BSID Base Station Identifier BU Binding Update CAC Connection Admission Control CAPL Contractual Agreement Preference List CCoA Collocated Care of Address CDMA2000 3rd Generation Code Division Multiple Access Radio Technology CGN Carrier Grade NAT CID Connection IDentifier CMAC Cipher-based Message Authentication Code CMIP Client Mobile IP COA Change of Authority CoA Care of Address COS Class of Service CR Core Router CS Convergence Sublayer CSN Connectivity Service Network CUI Chargeable User Identity DAD Duplicate Address Detection DHCP Dynamic Host Configuration Protocol DL Down Link diffserv Differentiated services DNS Domain Name Service DoS Denial of Service


Page - 13



DP Decision Point Data Path

DSL Digital Subscriber Line DSLAM Digital Subscriber Link Access Multiplexer E2E End-to-End E911 US Emergency Services EAP Extensible Authentication Protocol EAP-AKA EAP Authentication and Key Agreement to be used with USIM EAP-MD5 Extensible Authentication Protocol - Message Digest 5 EAP-MSCHAPv2

EAP Microsoft Challenge Handshake Authentication Protocol version 2

EAP-PSK Extensible Authentication Protocol - Pre Shared Key EAP-SIM EAP Subscriber Identity Module to be used with SIM EAP-TLS EAP with TLS EMSK Extended Master Session Key ertPS Extended Real-Time Polling Service EUI-64 Extended Unique Identifier (64-bit) FA Foreign Agent FBSS Fast Base Station Switching FCAPS Fault Configuration Accounting Performance and Security FQDN Fully Qualified Domain Name FRD Fast Router Discovery FWA fixed wireless access GPRS General Packet Radio Services GRE Generic Routing Encapsulation GSA Group Security Association GSM Global System for Mobile communication GW Gateway HA Home Agent HLA Hot-Line Application

Hot-Lining Application HLD Hot-Line Device

Hot-lining Device HMAC Keyed-Hashing for Message Authentication Code HO Handoff HO ID Handoff Identifier HoA MS Home Address Hotspot Public location such as an airport or hotel where WLAN services have been deployed HSDPA High Speed Downlink Packet Access HTTP HyperText Transfer Protocol I-WLAN Interworking with Wireless LANs IANA Internet Assigned Numbers Authority IBS Integrated Base Stations. Refers to a BS that can instantiate all the ASN functions for a given

MS. Such an Integrated BS can also be labeled an ASN. ICMPv6 Internet Control Message Protocol for (IPv6) Specification [RFC 2463] IE information elements IEEE Institute of Electrical and Electronics Engineers IEEE Std 802.3 IEEE standard specification for Ethernet IETF Internet Engineering Task Force


Page - 14



IID Interface Identifier IK Integrity Key IKEv2 Internet Key Exchange protocol version 2 IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IP Internet Protocol IPsec IP Security IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 ISF Initial Service flow IWF Internetworking Function IWG Inter-working Gateway IWU Internetworking Unit LBS Location Based Services LE License-Exempt deployments LMA Local Mobility Anchor LPF Local Policy Function LR Location Register MSID, BSID LSB Least Significant Byte LSN Large Scale NAT MAC Medium Access Control MAG Mobility Anchor Gateway MBMS Multimedia Broadcast/Multicast Service MCC Mobile Country Code MDHO Macro Diversity handoff MIP Mobile IP (Refers to both Mobile IPv4 and Mobile IPv6) MIP6 Mobile IP version 6 MM Mobility Management MMS Multimedia Messaging Service MNC Mobile Network operator Code MN_HOA Allow-MN-HA=Assignment MPLS Multi Protocol Label Switching MS Mobile Station MSID Mobile Station Identifier MSK Master Session Key NA Neighbor Advertisements NAI Network Access Identifier NAP Network Access Provider NAPT Network Address Port Translation NAS Network Access Server NAT Network Address Translation NMS Network Management System NRM Network Reference Model nrtPS Non-real-time Polling Service NS Neighbor Solicitation NSP Network Service Provider NUD Neighbor Unreachability Detection OAM Operations and Maintenance


Page - 15



OTA Over-The-Air OUI Organization Unique Identifier P-CSCF Proxy-Call Session Control Function PA Paging Agent PC Paging Controller PCRF Policy and Charging Rules Function. See [88] for further details. PDFID packet data flow ID PDG Packet Data Gateway PDU Packet Data Unit PEAP Protected EAP PF Policy Function PG Paging Group PG ID Paging Group Identifier PHS Packet header suppression (PHS) PKM Privacy Key Management PMIP Proxy-Mobile IP PMK Pairwise Master Key PMK2 Pairwise Master Key PMN Proxy Mobile Node PoA Point of Attachment PPAC prepaid accounting capability PPC Prepaid Client PPS Prepaid Server Proxy-ARP Proxy Address Resolution Protocol PSK PreShared Key PSTN Public Switched Telephone Network PtP Peer to Peer QoS Quality of Service RADIUS Remote Access Dial In User Service RA Router Advertisement RAPL Roaming Agreements Preference List RO route optimization RR Resource-Reservation RP Reference Point RRA Radio Resource Agent RRC Radio Resource Controller RRM Radio Resource Management RS Router Solicitation RSVP Resource Reservation Protocol rtPS Real-time Polling Service RUIM Removable User Identity Module SA Security Association SAE system architecture evolution SCI Spare capacity indicator S-CSCF Serving-Call Session Control Function SDFID service data flow ID SDU Service Data Unit SFA Service Flow Authorization


Page - 16



SFID Service Flow ID SFM Service Flow Management SHO Soft Hand Off SI Subscriber Identity SII System Information Identity or Service Identity Information SIM Subscriber Identity Module. Smart cards used by GSM operators. SLA Service Level Agreement SMTP Simple Mail Transport Protocol SNMP Simple Network Management Protocol SS7 Signaling System 7 SSL Secure Sockets Layer SS Subscriber Station SUBC Subscriber Credentials TBS Target BS TCP Transmission Control Protocol TE Terminal Equipment TLS Transport Layer Security, a variant of SSL TLV Type Length Value TTLS Tunneled TLS UDP User Datagram Protocol UDR Usage Data Record UE User Equipment UGS Unsolicited Grant Service UICC Universal Integrated Circuit Card UID user-identity UMTS Universal Mobile Telecommunications System USIM Universal Subscriber Identity Module. Smart cards used by UMTS operators VLAN Virtual LAN VoIP Voice over IP VPN Virtual Private Network VSA Vendor Specific Attributes WAG WLAN Access Gateway WATSP WiMAX® ASN Transport Signaling Protocols WCDMA Wideband Code-Division Multiple Access WEP Wired Equivalent Privacy WPA Wi-Fi® Protected Access Wi-Fi® Wireless Fidelity, refers to 802.11 standards, including 802.11b, 802.11a, and 802.11g WiMAX® Worldwide Interoperability for Microwave Access WLAN Wireless local area network based on IEEE Std 802.11 and related standards WWAN Wireless Wide Area Network X.509 ITU standard for digital public-key certificate issued by a CA

1


Page - 17


3. References 1

[1] IEEE Std 802.16-2004, IEEE Standard for Local and metropolitan area networks – Part 16: Air Interface for Fixed Broadband Wireless Access Systems

[2] IEEE Std 802.16e-2005, IEEE Standard for Local and metropolitan area networks – Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems – Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands

[3] Public EtherType Field Listings, http://www.iana.org/assignments/ethernet-numbers

[4] RFC792 – Internet Control Message Protocol (ICMP), J. Postel, September 1981

[5] RFC826 – An Ethernet Address Resolution Protocol (ARP), David C. Plummer, November 1982.

[6] RFC1027 – Using ARP to Implement Transparent Subnet Gateways, Smoot Carl-Mitchell and John S. Quarterman, October 1987

[7] RFC1349 – Type of Service in the Internet Protocol Suite, P. Almquist, July 1992

[8] RFC1678 – IPng Requirements of Large Corporate Networks, E. Britton and J. Tavs, August 1994, Informational

[9] RFC1701 - Generic Routing Encapsulation (GRE), S. Hanks, et al., October 1994, Informational

[10] RFC2119 – Key words for use in RFCs to Indicate Requirement Levels, S. Bradley, March 1997, Best Current Practice

[11] RFC2131 – Dynamic Host Configuration Protocol (DHCP), R. Droms, March 1997, Standards Track

[12] RFC2132 – DHCP O ptions and B OOTP V endor E xtensions, S . Alexander a nd R. D roms, M arch 1997, Standards track

[13] RFC2205 – Resource ReSerVation P rotocol (RSVP), R. Braden, et al ., September 1997, S tandards track

[14] RFC2327 – SDP: Session Description Protocol, M. Handley and V. Jacobson, April 1998, Standards Track

[15] RFC2461 – Simpson, Neighbor Discovery for IP Version 6 (IPv6), Narten and Nordmark, December 1998, Standards Track

[16] RFC2462 – IPv6 S tateless A ddress Auto-configuration, T homson a nd N arten, D ecember 1998, Standards Track

[17] RFC2474 – Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, K. Nichols, et al., December 1998, Standards Track

[18] RFC2475 – Architecture for Differentiated Services, S. Blake, et al., December 1998, informational

[19] RFC2597 – Assured Forwarding PHB Group, J. Heinanen, et al., June 1999, Standards Track

[20] RFC2598 – Expedited Forwarding PHB Group, V. Jacobson, et al., June 1999, Standards Track


Page - 18


[21] RFC2748 – The COPS (Common Open Policy Service) Protocol, D. Durham, et al ., January 2000, Standards Track

[22] RFC2794 – Mobile I P N etwork Access I dentifier E xtension f or IPv4, P. Calhoun a nd C . P erkins, March 2000, Standards Track

[23] RFC2865 – Remote Authentication Dial In User Service (RADIUS), C. Rigney, et al., June 2000, Standards Track

[24] RFC2866 – RADIUS Accounting, C Rigney and Livingston, June 2000, Informational

[25] RFC2904 – AAA Authorization Framework, J. Vollbrecht, et al., August 2000, Informational

[26] RFC2905 – AAA Authorization Application E xamples, J . V ollbrecht, e t a l., August 2000, Informational

[27] RFC2906 – AAA Authorization Requirements, S. Farrell, et al., August 2000, Informational

[28] RFC3012 – Mobile I Pv4 Challenge/Response E xtensions, C . P erkins a nd P . C alhoun, N ovember 2000, Standards Track

[29] RFC 3024 – Reverse T unneling for M obile I P, r evised, G. M ontenegro, J anuary 2001, S tandards track

[30] RFC3041 – Privacy E xtensions f or S tateless Address Autoconfiguration i n I Pv6, N arten, D raves, January 2001, Standards Track

[31] RFC3046 – DHCP Relay Agent Information Option, M. Patrick, January 2001, Standards Track

[32] RFC3084 – COPS Usage for Policy Provisioning (COPS-PR), K. Chan, et al., March 2001, Standards Track

[33] RFC3115 – Mobile IP Vendor/Organization-specific extensions, G. Dommety and K. Leung, April 2001, Standards Track

[34] RFC3118 – Authentication for DHCP Messages, R. Droms and W. Arbaugh, June 2001, Standards Track

[35] RFC3159 – Structure of Policy Provisioning Information (SPPI) K. McCloghrie, et al., August 2001, Standards Track

[36] RFC3162 – RADIUS and IPv6, B. Aboba, et al., August 2001, Standards Track

[37] RFC3173 – IP P ayload C ompression P rotocol ( IPComp), A . S hacham, e t a l., S eptember 2001, Standards Track

[38] RFC3203 – DHCP Reconfigure Extension, Y. T’Joens, et al., December 2001, Standards Track

[39] RFC3264 – An Offer/Answer Model with the Session Description Protocol (SDP), J. Rosenberg and H. Schulzrinne, June 2002, Standards Track

[40] RFC3312 – Integration of Resource Management and Session Initiated Protocol, G. Camarillo, et al., October 2002, Standards Track


Page - 19


[41] RFC3313 – Priv ate Session In itiation Pro tocol (SIP) Extensions fo r Med ia Au thorization, W. Marshall, January 2003, Informational

[42] RFC3315 – Dynamic Host Configuration Protocol for IPv6 (DHCPv6, R. Droms, et al., July 2003, Standards Track

[43] RFC3344 – Mobile IP support for IPv4, C. Perkins, August 2002, Standards Track

[44] RFC3520 – Session Authorization Policy Element, L-N. Hamer, et al., April 2003, Standards Track

[45] RFC3543 – R egistration R evocation i n Mobile IP v4, S. Gl ass an d M. C handra, Au gust 2 003, Standards Track

[46] RFC3556 – S ession De scription P rotocol (SDP) B andwidth M odifiers for R TP C ontrol Protocol (RTCP) Bandwidth, S. Casner, July 2003, Standards Track

[47] RFC3565 – Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), J. Schaad, July 2003, Standards Track

[48] RFC3576 – Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), M. Chiba, et al., July 2003, Informational

[49] RFC3579 – RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP), B. Aboba and P. Calhoun, September 2003, Informational

[50] RFC3588 – Diameter Base Protocol, P. Calhoun, et al., September 2003, Standards Track

[51] RFC3736 – Stateless Dy namic Ho st C onfiguration P rotocol ( DHCP) S ervice for IPv6, R . Droms, April 2004, Standards Track

[52] RFC3748 – Extensible Authentication Protocol, B. Aboba, et al., June 2004, Standards Track

[53] RFC3775 – Mobility Support in IPv6, D. Johnson, C. Perkins, J. Arkko, June 2004, Standards Track

[54] WMF-T33-001-R016, W iMAX Foru m® Net work A rchitecture, Det ailed Protocols and Procedures, Base specification

[55] RFC3957 – A uthentication, Aut horization, and Acco unting (A AA) Registration Key s for Mobile IPv4, C. Perkins and P. Calhoun, March 2005, Standards Track

[56] VO ID

[57] dra ft-ietf-eap-netsel-problem-05.txt

[58] RFC4285 – Authentication Protocol for Mobile IPv6, A. Patel, et al., January 2006, Informational

[59] RFC4283 – Mobile Node Iden tifier Option for MIPv6, A. Patel, et al., November 2005 , Standards Track

[60] RFC4282 – The Network Access Identifier, B. Aboba, et al., December 2005, Standards Track

[61] dra ft-ohba-eap-aaakey-binding-01.txt


Page - 20


[62] TR-025 – DSL Forum, “Core Network Architecture for Access to Legacy Data Network over ADSL”, Nov-1999

[63] TR-044 – DSL Forum , “Auto-Config for Basic Internet (IP-based) Services, “ Nov-2001

[64] TR-059 – DSL Forum, “DSL Evolution – Architecture Requirements for the Support of QoS-Enabled IP Services,” Sept-2003

[65] 3GPP TR 22.934 V6.2.0 (20 03-09) “Feasib ility St udy o n 3GPP syste m to Wireless Lo cal Area Network (WLAN) interworking (Release 6)”

[66] 3GPP TR 23.981 V6.3.0 (2005-03) “ Interworking aspects and migration scenarios for IPv4 based IMS Implementations”

[67] 3GPP TS 23.002 V6.9.0 (2005-10) “Technical Speci fication Group Services and Sy stems Aspects; Network architecture (Release 6)”

[68] 3GPP TS 2 3.234 V 6.5.0 ( 2005-06) “3 GPP sy stem t o W ireless Lo cal Area Net work (WLAN) interworking; System description (Release 6)”

[69] 3GPP TS 23.207 V6 .6.0 (2005-10) “End-to-end Quality o f Service (QoS) co ncept and arch itecture (Release 6)”

[70] 3GPP TS 23.228 V6.10.0 (2005-06) “IP Multimedia Subsystem (IMS); Stage 2, (Release 6)”

[71] 3GPP TS 24.229 V6.8.0 (2005-10) “Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)”

[72] 3GPP TS 24.234 V6.3.0 (2005-06) “3G PP System to W ireless Lo cal A rea Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3 (Release 6)”

[73] 3GPP TS 2 9.234 V 6.4.0 ( 2005-10) “ 3GPP syste m to W ireless Local Area Net work (WLAN) interworking; Stage 3”

[74] 3GPP TS 33.234 V 6.5.1 (2005-06) “Wireless Local A rea Net work (WLAN) interworking security (Release 6)”

[75] TR-101 – DSL Forum, "Migration to Ethernet-Based DSL Aggregation", Apr-2006

[76] 3GPP2 X.S0013-000-0 v2.0 “All-IP Core Network Multimedia Domain – Overview,” Aug-2005

[77] 3GPP2 X.S0013.00200 v1.0 “All- IP Core Network Multimedia Domain: IP Mu ltimedia Subsystem Stage 2,” Feb-2004

[78] 3GPP2 X.S0013-004-0 v1.0 “All-IP Core Network Multimedia Domain: IP Multimedia Call Control Protocol Based on SIP and SDP Stage 3,” Feb-2004

[79] WMF-T31-001-R015, WiMAX Forum® Network Requirements, Recommendations and Requirements for Networks based on WiMAX Forum Certified® Products

[80] IEEE Std 802.16g-2007, IEEE Standard for Local and metropolitan area networks – Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems – Amendment 3: Management Plane Procedures and Services


Page - 21


[81] RFC 4017 – EAP Method Requirements for Wireless LAN, D. Stanley, J. Walker, B. Aboba, March 2005, Informational.

[82] MEF 6, Ethernet Service Definitions - Phase 1, MEF, June 2004.

[83] MEF10.1, Ethernet Service Attributes - Phase 2, MEF, November 2006.

[84] IEEE Std 802.1ad-2005, IEEE Standard for Local and metropolitan area networks; Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges.

[85] draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-07.txt: Transmission of IP over Ethernet over IEEE 802.16 Networks.

[86] MEF 6.1, Ethernet Services Definitions - Phase 2, MEF, April 2008.

[87] "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 16-May-08, <draft-ietf-dhc-l2ra-01.txt>.

[88] WM F-T33-109-R016, WiMAX Forum® Network Architecture, Policy and Charging Control

[89] RFC 4072 - Diameter Extensible Authentication Protocol (EAP) Application, P. Eronen, T. Hiller, G. Zorn, August 2005, Standards Track.

[99] RFC 5213, “Proxy Mobile IPv6”

[100] Internet-Draft “IPv4 Support for Proxy Mobile IPv6” (draft-ietf-netlmm-pmip6-ipv4-support-09)

[101] Internet-Draft “GRE Key Option for Proxy Mobile IPv6” (draft-ietf-netlmm-grekey-option-06)

[102] Internet-Draft “GRE Key Extension for Mobile IPv4” (draft-yegani-gre-key-extension-03)

[103] Requirements for WiMAX Priority Access for Emergency Telecommunications Service (ETS) – Phase 1, Feb. 2009.

[104] 3GPP TS 29.214, Policy and Charging Control over Rx Reference Point, Release 7.

[105] IEEE Std 802.16-2009, IEEE Standard for Local and metropolitan area networks – Part 16: Air Interface for Broadband Wireless Access Systems

1


Page - 22


4. Identifiers 1

4.1 Identifiers Used in Stage-2 document 2

4.1.1 Introduction 3 This section provides at one place a list of various identifiers used in a WiMAX® network. The following table is an 4 exhaustive list of those identifiers. Each identifier is accompanied with a f ew key attributes (like scope, size, etc.) 5 and a short description on its usage. 6

4.1.2 List of Identifiers 7

Identifier Type Size Definition (Stage-2 section or reference to external source)

Scope (area of validity)

MS ID

binary 48 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] Global

Each WiMAX® subscriber station is provisioned with a unique 48-bit MAC address by the manufacturer. It is used in 802.16 management messages to address the MS prior to allocation of CIDs. It is transferred as part of context during handover.

NAI

character variable up to 253 bytes RFC 4282 [60] Global

NAI is allocated to a WiMAX subscriber by its home operator and serves as primary ID for AAA purposes. WiMAX networks use NAI as defined in [60] instead of RFC2486 because the draft allows for decorated NAIs which are necessary for roaming. Although actually separate name space, NAIs are administered together with FQDNs.

HoA

binary 4 octets / 16 octets Section 2.1.48 Global / NSP

HoA belongs to the address range allocated to the NSP. It is either a globally valid IPv4 or IPv6 address or allocated from the private address space range. In the second case its scope is CSN. HoA’s primary use is to route MS’s IP packets from internet to home or visited CSN. The CSN uses tunneling to deliver packets to ASN. HoA is also used for classifications to determine the tunnel tag.

Flow ID

binary less than or equal to 4 bytes

7.7 MS

Used by the accounting framework to identify IP flows in primitives between CSN and ASN. Packet Data Flow ID always identifies a single unidirectional or bidirectional flow. A unidirectional Packet Data Flow ID maps to a single SFID while bidirectional Packet Data Flow ID maps to exactly two SFIDs. Packet Data Flow ID is always allocated by AAA server.

Service flow ID (SFID)

binary 32 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] MS

Each service flow represents a single unidirectional WiMAX radio interface connection with guaranteed QoS parameters. Service flows could be pre-provisioned or dynamically created. SFID doesn’t change during Intra-NAP handover. Note that Service Flows according 802.16 should not be confused with Service Flows as used in QoS Framework of IETF.


Page - 23




Connection ID (CID)

binary 16 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] BS

CID represents a unidirectional connection between BS and MS and it is used to address the MS when it is attached to a BS.

Data Path ID

binary variable 7.7 NAP

Data Path ID is used to identify the tunnel carrying MS traffic between ASN gateways or between the ASN gateway and base station. This specification allows only for GRE key to be used as data path ID.

HO ID

binary 8 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] Target BS

Allocated by target BS and used instead of MS MAC to send the RNG_REQ during network re-entry for non-contention based ranging. Used for R6/R8 and R4 MM.

Paging Controller ID

binary 48 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] NAP

Paging controller ID is a unique identity of a network entity which retains the MS state and operational parameters while MS is in idle mode. The Paging Controller ID parameter is signaled by MS during network re-entry and location update procedures.

PG ID

binary 16 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] NAP

Base stations are organized into paging groups, and each group is assigned a paging group ID. When the subscriber is paged, it is paged in all base stations belonging to its current paging group.

BS ID

binary 48 bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] Global

BS ID is a global unique identifier for a WiMAX® base station, as defined in the IEEE 802.16-2004 and IEEE 802.16-2005 standard represents one logical instance of a PHY and MAC function providing 802.16 radio connectivity services to an SS/MS (equivalent to a single frequency sector of a physical base station). The upper 24 bits contain unique identifier of a NAP (NAP ID), while lower 24 bits are used to differentiate between NAP's base stations. BS ID is programmable and is regularly broadcasted by the PHY/MAC in the DL-MAP message. Note that a physical multi-sector cell site implementation SHALL include multiple BS IDs.

Operator ID

binary 24-bits IEEE Std 802.16-2004 and IEEE Std 802.16e-2005 [1] and [2] Global

Operator ID is a globally unique identifier of WiMAX network access provider, and is alternatively termed NAP ID. The upper 24 bits of BS ID always contain operator ID of the NAP.

NSP ID

binary 24 bits Part 2 Section 7.1.4.2 Global

NSP ID is a globally unique identifier of a WiMAX network service provider. NSP ID(s) is broadcasted on a regular basis by a base station, and it can be also solicited by the MS.


Page - 24




Anchor Data Path FunctionID

binary 4 /6 / 16 octets 7.7 NAP

Uniquely identifies the ASN GW to which the CSN sends the downlink user plane traffic.

Authenticator ID

binary 4 /6 / 16 octets

Delivered in Intra ASN primitives (e.g. micro mobility, paging) NAP/NSP

IP address or other ID for the Authenticator.

4.2 Network Addressable Identifiers for Inter-ASN Communications 1

When several ASNs are engaged in communication, they may use the following four Identifiers in order to address 2 the network entities located within the communicating ASNs: 3

1. Base Station ID. 4 2. Authenticator ID. 5 3. Anchor Data Path Function ID (Anchor ASN GW ID). 6 4. Paging Controller ID. 7

8

These Identifiers are referred to as Network Addressable Identifiers. Network Addressable Identifier is a generic 9 term. It can take form of 6-octet IEEE Std 802.16e Identifier (e.g. BS ID, PC ID), IPv4 Address or IPv6 Address. 10


Page - 26


5. Tenets for WiMAX® Network Systems Architecture 1 The t enets p resented i n t his s ection ar e i ndependent o f particular r eleases o f t he W iMAX® Network S ystems 2 Architecture. 3

5.1 General 4

a) The architecture framework and Network Reference Model (NRM) SHALL accommodate al l WiMAX®-5 based usage models as defined in the Stage 1 requirements specification [79]. 6

b) The W iMAX ar chitecture, b ased o n a p acket-switched framework, SHALL be ba sed on t he IE EE Std 7 802.16 and its amendments and use appropriate IETF RFCs and IEEE Ethernet standards. In the event that 8 currently defined IETF protocols do not satisfy a solution requirement, extensions (some possibly unique to 9 WiMAX) MAY be specified. 10

c) The architecture f ramework SHALL permit decoupling o f access architecture (and supported topologies) 11 from co nnectivity IP services and consider network elements o f t he connectivity serving network ( CSN) 12 agnostic to the IEEE Std 802.16 radio specifics. 13

d) The WiMAX network a rchitecture f ramework SHALL be ba sed on f unctional de composition pr inciples 14 (i.e. d ecomposition o f features in to functional e ntities a cross in teroperability r eference p oints, without 15 specific i mplementation a ssumptions i ncluding t he notion o f network en tities an d interfaces). S uch a 16 framework SHALL be modular and flexible enough to accommodate a broad range of deployment options 17 such as: 18

o Small-scale to large-scale (sparse to dense radio coverage and capacity) WiMAX networks, 19

o Urban, suburban and rural radio propagation environments, 20

o Licensed and/or licensed exempt frequency bands, 21

o Hierarchical, flat, or mesh topologies, and their variants, 22

o Co-existence of fixed, nomadic, portable and mobile usage models. 23

e) The WiMAX architecture SHALL employ use of native IEEE Std 802.16 procedures and logical separation 24 between s uch p rocedures a nd I P a ddressing, r outing a nd c onnectivity management p rocedures a nd 25 protocols to enable use o f the access ar chitecture p rimitives i n standalone and i nterworking deployment 26 scenarios. 27

f) The architecture SHALL support sharing of a NAP’s ASN(s) by multiple NSPs. 28

g) The architecture SHALL support a single NSP providing service over multiple ASN(s) – managed by one 29 or more NAPs. 30

h) The architecture SHALL support the discovery and selection of accessible NSPs by an MS. 31

i) The architecture SHALL support NAPs that employ one or more ASN topologies. 32

j) The architecture SHALL support access to incumbent operator services through internetworking functions 33 as needed. 34

k) The architecture SHALL specify open, published and accepted standards based and well-defined reference 35 points between various groups of network functional entities (within an ASN, between ASNs, between an 36 ASN and a C SN, and between CSNs), and in particular between an MS, ASN and CSN to enable multi-37 vendor interoperability. 38

l) The ar chitecture S HOULD b e f lexible s o i t i s l ikely t hat i t acco mmodates future en hancements t o t he 39 IEEE802.16 suite of standards. 40

m) The architecture SHOULD be able to accommodate documented geo-specific constraints. 41

n) The architecture SHOULD support evolution paths between the various usage models subject to reasonable 42 technical assumptions and constraints. 43


Page - 27


o) The architecture SHALL not preclude different vendor implementations based on different combinations of 1 functional e ntities o n p hysical n etwork e ntities, a s lo ng a s th ese i mplementations c omply with the 2 normative protocols and procedures across applicable reference points, as defined in this specification. 3

p) The architecture SHALL support the most trivial scenario of a single operator deploying an ASN together 4 with a limited set of CSN functions, so that the operator can offer basic Internet access service without 5 consideration for roaming or interworking. 6

q) The ar chitecture S HALL s upport n etwork b ased S imple I P s olution i n which no M IP-based n etwork 7 elements are used in the WiMAX network. 8

r) The architecture SHALL allow co-existence and concurrent operation of Simple IP, Client Mobile IP and, 9 Proxy Mobile IP services in the Access Service Network and Connectivity Service Network for IPv4 and 10 IPv6. 11

s) The a rchitecture S HALL s upport t he A ccounting, C harging, a nd S ettlement R equirements for a ll us age 12 scenarios without dependencies on Simple IP or Mobile IP network configuration. 13

5.2 Services and Applications 14

The architecture SHALL be capable of supporting voice, multimedia services and other mandated regulatory 15 services such as emergency services and lawful interception. 16

t) The architecture SHALL be agnostic to and support access to a variety of independent Application Service 17 Provider (ASP) networks. 18

u) The architecture SHALL support mobile telephony communications using VoIP and, in applicable roaming 19 scenarios, S HALL s upport in ter-operator pol icy de finition, di stribution a nd e nforcement a s needed f or 20 voice communications. The following capabilities SHALL apply (subject to specific services offered and 21 provisioned): 22

o The architecture SHALL support SLA-based resource management for subscribers, 23

o The ar chitecture S HALL s upport m ore t han o ne v oice s ession ( when ap plicable) t o t he p articular 24 subscriber, 25

o The architecture SHALL support simultaneous voice and data sessions, 26

o The architecture SHALL support prioritization (including pre-emption) for emergency voice calls and 27 high priority data sessions. 28

v) The ar chitecture S HALL s upport i nterfacing with v arious interworking a nd media ga teways p ermitting 29 delivery o f i ncumbent/legacy s ervices t ranslated o ver I P ( for ex ample, SMS o ver I P, M MS, W AP) t o 30 WiMAX® access networks. 31

w) The ar chitecture S HALL s upport d elivery o f I P B roadcast an d M ulticast s ervices o ver W iMAX a ccess 32 networks. 33

x) The architecture SHALL support Ethernet services as an option for the implementation as defined in the 34 requirements of the WiMAX Forum SPWG for Rel. 1.5. 35

5.3 Security 36

The W iMAX® security framework S HALL b e ag nostic t o t he o perator t ype an d A SN topology a nd a pply 37 consistently acr oss G reenfield an d i nternetworking d eployment models an d u sage s cenarios ( where 38 possible). 39

The architecture SHALL accommodate support for s trong mutual MS authentication between an MS and the 40 WiMAX network, based on the IEEE Std 802.16 security frameworks. 41

An MS SHOULD be able to support all commonly deployed authentication mechanisms and authentication in 42 home and visited o perator n etwork scenarios based o n a consistent and e xtensible au thentication 43 framework. An MS SHOULD be ab le to select between various authentication method(s) based on NSP 44 type. 45


Page - 28


The a rchitecture S HALL s upport d ata in tegrity, r eplay p rotection, c onfidentiality a nd n on-repudiation u sing 1 applicable key lengths within the WiMAX Access Network. 2

The architecture SHALL accommodate the use of MS initiated/terminated security mechanisms such as Virtual 3 Private Networks (VPNs). 4

The architecture SHALL accommodate standard secure IP address management mechanisms between the MS 5 and its home or visited NSP. 6

Unless ex plicitly p ermitted, t he ar chitecture S HOULD en sure MS an d h ost’s s pecific s tates s uch as – 7 authentication s tate, I P H ost c onfiguration, s ervice p rovisioning a nd service a uthorization a re no t 8 inadvertently shared with other users/SS/MSs. 9

As r equired a nd s pecified i n I EEE 802. 16 a nd a pplicable I ETF I P pr otocol s pecifications, group 10 communications SHALL be restricted to authorized group membership. 11

5.4 Mobility and Handovers 12

The architecture S HALL NOT preclude i nter-technology h andovers – e.g., to Wi-Fi®, 3G PP, 3G PP2, 13 DSL/MSO – when such capability is enabled in multi-mode MS. 14

The architecture SHALL accommodate IPv4 or IPv6 based mobility management. Within this framework, and 15 as applicable, the architecture SHALL accommodate MS with multiple IP addresses and simultaneous IPv4 16 and IPv6 connections. 17

The ar chitecture SHALL N OT p reclude r oaming b etween N SPs. T he ar chitecture S HOULD al low a single 18 NAP to serve multiple MSs using different private and public IP domains owned by different NSPs (except 19 where solutions become technically infeasible). The NSP MAY be one operator or a group of operators 20 (e.g., Visited Operator MAY be different from the Home Operator and the Home Operator MAY delegate 21 mobility unrelated service aspects to third party ISPs). 22

The ar chitecture S HALL s upport m echanisms t o s upport s eamless handovers a t up t o v ehicular s peeds –23 satisfying bounds of service disruption as specified in Stage 1. 24

The architecture SHALL support dynamic and static home address configurations. 25

The architecture SHALL allow for dynamic assignment of the Home Agent in the service provider network as a 26 form of route optimization, as well as in the home IP network as a form of load balancing. 27

The ar chitecture S HALL a llow for d ynamic a ssignment o f t he H ome Agent i n H -CSN or V -CSN b ased on 28 policies. 29

The architecture shall support the mobility management requirements associated with the fixed, nomadic, and 30 mobile usage scenarios such as the mobility restriction of fixed and nomadic users. 31

5.5 Quality of Service 32

To f lexibly support s imultaneous u se o f a d iverse s et o f I P s ervices, t he ar chitecture f ramework S HALL 33 support: 34

o Differentiated levels of QoS – coarse-grained (per user/SS/MS) and/or fine-grained (per service flow 35 per user/SS/MS), 36

o Admission control, 37

o Bandwidth management. 38

y) The architecture SHALL support the means to implement policies as defined by various operators for QoS 39 based on their SLAs, which MAY require policy enforcement per user and user group as well as factors 40 such as location, time of day, etc. QoS policies MAY be synchronized between operators depending on 41 subscriber SLAs, accommodating for the fact that not all operators MAY implement the same policies. 42

z) The a rchitecture S HALL u se s tandard I ETF m echanisms f or managing p olicy d efinition a nd p olicy 43 enforcement between operators. 44


Page - 29


5.6 Scalability, Extensibility, Coverage and Operator Selection 1

The WiMAX® Access Service Network (ASN) architecture SHALL enable a user to manually or automatically 2 select from available NAPs and NSPs. 3

The architecture SHALL enable ASN and CSN system designs that easily scale upward and downward – in 4 terms of coverage, range or capacity. 5

The architecture SHALL accommodate a v ariety o f ASN topologies – including hub-and-spoke, h ierarchical, 6 flat, and/or multi-hop interconnects. 7

The architecture SHALL accommodate a variety o f backhaul l inks, both wireline and wireless with d ifferent 8 latency and throughput characteristics. 9

The architecture SHALL support incremental infrastructure deployment. 10

The architecture SHALL support phased introduction of IP services that in turn scale with increasing number of 11 active users and concurrent IP services per user. 12

The ar chitecture S HALL s upport t he i ntegration o f b ase s tations o f v arying co verage an d cap acity – for 13 example, pico, micro, and macro base stations. 14

The ar chitecture SHALL support flexible d ecomposition a nd i ntegration o f ASN functions i n ASN network 15 deployments i n or der t o e nable u se of l oad ba lancing s chemes f or e fficient u se of r adio s pectrum a nd 16 network resources. 17

5.7 Interworking and Roaming 18

The architecture SHALL support loosely-coupled in terworking with e xisting wireless networks ( for example, 19 3GPP, 3 GPP2) o r w ireline ne tworks ( for e xample D SL). I n a ll s uch i nterworking i nstances, t he 20 interworking interface(s) SHALL be based on standard IETF and IEEE suite of protocols. 21

The ar chitecture SHALL support g lobal r oaming acr oss WiMAX® operator n etworks, i ncluding support f or 22 credential reuse, consistent use of AAA for accounting and charging, and consolidated/common billing and 23 settlement. 24

The architecture SHALL support a variety of user authentication credential formats such as username/password, 25 digital cer tificates, S ubscriber I dentity M odule ( SIM), U niversal S IM ( USIM), an d Removable U ser 26 Identify Module (RUIM). 27

5.8 Manageability 28

The ar chitecture S HALL acc ommodate a v ariety o f o nline a nd o ffline c lient p rovisioning, e nrollment, a nd 29 management schemes based on open, broadly deployable, industry standards. 30

The architecture SHALL accommodate Over-The-Air (OTA) services for MS SS/MS provisioning and software 31 upgrades. 32

5.9 Performance 33

The architecture SHALL accommodate use of header compression/suppression and/or payload compression for 34 efficient use of the WiMAX® radio resources. 35

The ar chitecture S HALL s upport m echanisms t hat e nable maximum p ossible en forcement a nd fast r e-36 establishment of established QoS SLAs due to handover impairments. 37

5.10 Multi-vendor Interoperability 38

The architecture SHOULD support interoperability between equipment from different manufacturers within an 39 ASN and across ASNs. Such interoperability SHALL include: 40

o Interoperability between BS and backhaul equipment within an ASN. 41


Page - 30


o Interoperability be tween v arious ASN e lements ( possibly f rom di fferent vendors) a nd C SN, with 1 minimal or no degradation in functionality or capability of the ASN. 2

5.11 Convergence Sublayers (CS) 3

The IEEE Std 802.16 defines multiple convergence s ub l ayers. T he network a rchitecture f ramework SHALL 4 support the following CS types: 5

o Ethernet CS and IPv4/IPv6 over Ethernet CS, 6

o IPv4 CS, 7

o IPv6 CS. 8


Page - 31


6. Network Reference Model 1

6.1 Overview 2

The Network Reference Model (NRM) is a l ogical representation of the network architecture. The NRM identifies 3 functional entities and reference points over which interoperability is achieved between functional entities. 4

Figure 6-1 illustrates the NRM, consisting of the following logical entities: MS, ASN, and CSN, whose definitions 5 were given in Section 2.1. The figure depicts the normative reference points R1-R6 and R8. 6

Each of the entities, MS, ASN and CSN represent a grouping of functional entities. Each of these functions MAY be 7 realized in a single physical functional entity or MAY be distributed over multiple physical functional entities. The 8 ASN defines an administrative boundary and consists of one or more Base Station(s) and at least one ASN-GW. 9

The intent o f the NRM is to allow multiple implementation options for a given functional entity, and yet achieve 10 interoperability a mong d ifferent r ealizations o f f unctional e ntities. I nteroperability i s based o n th e d efinition o f 11 communication pr otocols a nd da ta path treatment b etween f unctional en tities to ach ieve an o verall e nd-to-end 12 function, for example, security or mobility management. Thus, the functional entities on either side of RP represent 13 a c ollection o f c ontrol a nd data p ath end-points. I n t his s etting, i nteroperability will b e v erified ba sed onl y on 14 protocols exposed across an RP, which would depend on the end-to-end function or capability realized (based on the 15 usage scenarios supported by the overall network). 16

This doc ument specifies t he n ormative use of pr otocols o ver a n R P for s uch a s upported c apability. If a n 17 implementation claims support for the capability and exposes the RP, then the implementation SHALL comply with 18 this s pecification. This av oids t he s ituation where a p rotocol en tity ca n r eside o n ei ther s ide o f a n RP o r t he 19 replication of identical procedures across multiple RPs for a given capability. 20


Page - 32


CSN

BS

ASNGW

Another ASN ASP NetworkOR Internet

CSN

BS

MS

ASP NetworkOR Internet

ASN

R2

R1

R3 R5

Mobile WiMAX Network Reference PointControl and Data Path Control only

R6

R6

R8

R4

1

Figure 6-1 - Network Reference Model 2

The Network Reference Model with all its reference points is applicable for providing access to IP services as well 3 as Ethernet services. Ethernet services connectivity to the Internet or to other IP services is out of scope. 4

6.2 Reference Points 5

Figure 6-1 introduces several interoperability reference points. A reference point is a conceptual point between two 6 groups of functions that resides in different functional entities on either side of i t. These functions expose various 7 protocols a ssociated with a n R P. A ll p rotocols a ssociated with a R P M AY not a lways te rminate i n t he same 8 functional e ntity i.e., t wo protocols as sociated with a RP SHALL b e able t o o riginate and t erminate i n d ifferent 9 functional e ntities. T he n ormative r eference p oints b etween t he major f unctional e ntities a re in the following 10 subsections. 11

All the reference points defined in this specification are normative. 12

6.2.1 Reference Point R1 13 Reference P oint R1 consists o f the protocols an d p rocedures between M S and the BS o f the ASN as p er the ai r 14 interface (PHY and MAC) specifications according to the WiMAX Forum® Mobile System Profile. Reference point 15 R1 MAY include additional protocols related to the management plane. 16

6.2.2 Reference Point R2 17 Reference Point R2 consists of protocols and procedures between the MS and CSN associated with Authentication, 18 Services Authorization and IP Host Configuration management. 19

This r eference p oint i s l ogical i n t hat i t d oes not r eflect a d irect p rotocol i nterface b etween M S a nd CSN. T he 20 authentication part of reference point R2 runs between the MS and the CSN operated by the home NSP, however the 21 ASN and CSN operated by the visited NSP MAY partially process the aforementioned procedures and mechanisms. 22


Page - 33


Reference P oint R 2 might s upport I P H ost C onfiguration M anagement r unning b etween t he M S a nd t he CSN 1 (operated by either the home NSP or the visited NSP). 2

6.2.3 Reference Point R3 3 Reference Point R3 consists of the set of control protocols between the ASN and the CSN to support AAA, policy 4 enforcement and mobility management capabilities. I t also encompasses the data path methods (e.g., tunneling) to 5 transfer user data between the ASN and the CSN. 6

6.2.4 Reference Point R4 7 Reference Point R4 consists of the set of control and data path protocols originating/terminating in an ASN-GW that 8 coordinate MS mobility between ASNs and ASN-GWs. R4 is the only interoperable RP between the ASN-GWs of 9 one ASN or two different ASNs. 10

6.2.5 Reference Point R5 11 Reference Point R5 consists of the set of control and data path protocols for internetworking between the CSNs, e.g. 12 CSNs operated by the home NSP and that operated by a visited NSP. 13

6.2.6 Reference Point R6 14 Reference point R6 consists of the set of control and data path protocols for communication between the BS and the 15 ASN-GW within a single ASN. The data path consists of intra-ASN data path between the BS and ASN-GW. The 16 control protocols comprises functions for data path establishment, modification, and release control in accordance 17 with the MS mobility events. However, when protocols and primitives over R8 are available, MAC states will not be 18 exchanged over R6. 19

6.2.7 Reference Point R7 20 Deprecated in Release 1.5. 21

6.2.8 Reference Point R8 22 Reference Point R8 is intra-ASN and consists of the set of control message flows between the base stations to ensure 23 fast a nd seamless ha ndover. The control ´plane co nsists o f the inter-BS c ommunication p rotocol in lin e with the 24 WiMAX F orum® Mobile S ystem P rofile and a dditional set o f p rotocols t hat a llow c ontrolling the d ata tr ansfer 25 between the Base Stations involved in handover of a certain MS. 26

6.3 ASN Reference Model 27

6.3.1 ASN Definition 28 The ASN consists of ASN-GW(s) and Base Station(s), and include all functional entities required to provide access 29 services. An ASN shares R1 reference point (RP) with an MS, R3 RP with a C SN and R4 RP with another ASN-30 GW. The ASN consists of at least one instance of a Base Station (BS) and at least one instance of an ASN Gateway 31 (ASN-GW). 32


Page - 34


BS

BS

ASNR1 R3

R6

R6

R8

R4

ASNGW1

ASNGWn

R1 R3

R4

R6

1

Figure 6-2 - ASN Reference Model containing multiple ASN-GWs 2

Within an ASN, a BS may be logically connected to more than one ASN-GW for different MSs. For a given MS, a 3 BS is connected to a single ASN-GW. 4

6.3.2 BS Definition 5 The WiMAX® Base Station (BS) is a logical entity that embodies a full instance of the WiMAX MAC and PHY in 6 compliance with the IEEE 802.16 suite of applicable standards and MAY host one or more access functions. A BS 7 instance represents o ne sector with one frequency assignment. It incorporates scheduler functions for uplink and 8 downlink r esources, which will be l eft for v endor i mplementation a nd i s ou tside t he s cope of t his doc ument. 9 Connectivity (i.e. reachability) of a single BS to more than one ASN-GW MAY be required for load balancing or a 10 redundancy option. BS is logical entity and one physical implementation of BS can have multiple BSs. 11

6.3.3 ASN Gateway Definition 12 The ASN Gateway (ASN-GW) is a logical entity that represents an aggregation of Control Plane functional entities 13 that are either paired with a corresponding function in the ASN (e.g. BS instance), a resident function in the CSN or 14 a function in another ASN. The ASN-GW MAY also perform Bearer Plane routing or bridging function. 15

ASN-GW i mplementation MAY i nclude r edundancy and l oad-balancing a mong s everal ASN-GWs. T he 16 implementation details are out of scope for this document. 17

For every MS, a B S is associated with exactly one default ASN GW. However, ASN-GW functions for every MS 18 may be distributed among multiple ASN-GWs located in one or more ASN(s). 19

6.3.4 Functional Decomposition of ASN Architecture 20 NOTE-1: The ASN Architecture is functionally decomposed based on what used to be known as ASN Profile C in 21 WiMAX Forum® Network Architecture Release 1.0 22

NOTE-2: An ASN may be implemented in a fashion that only exposes external reference points R1, R3, and R4 and 23 doesn’t expose R6 and R8. One example of this implementation is an ASN comprised of a single physical element 24 (e.g. Integrated BS/GW) supporting the BS and ASN-GW functions. 25

ASN functions are mapped into ASN-GW and BS as shown in Figure 8-3. Key attributes of ASN functions are: 26

a) HO Control is in the Base Station. 27

RRC is in the BS that would a llow RRM within the BS. An “RRC Relay” is in the ASN GW, to relay the RRM 28 messages sent from BS to BS via R6. 29

30


Page - 35


Data Path Function (Type1)

Context Function

Handover Fn. (Relay)

PMIP Client

AAA Client

RRM Relay

Location Register

Paging Controller

Authenticator

DHCP Proxy/Relay

Key Distributor

Srv. Flow Auth.

MIP FA

ASN-GW

BS

R3

R4*

R6

*ASN Anchored Mobility shall be possible over R6 and R4.

Data Path Function (Type 1)

Handover Function

Srv. Flow Mgnt.

RRA

Key Receiver

Auth. Relay RRC

Context Function

ASN

Paging Agent

1

Figure 6-3 - Functional View of ASN 2

When ASN is composed of n ASN-GWs (where n > 1), Intra ASN mobility MAY involve R4 control messages and 3 Bearer Plane establishment. For all applicable protocols and procedures, the Intra-ASN reference point R4 SHALL 4 be fully compatible with the Inter-ASN equivalent. 5

Table 6-1 illustrates the reference points over which intra-ASN interoperability is achieved in accordance with ASN 6 architecture. 7

Table 6-1 - Interoperability Reference Points 8

Function Categories

Function ASN Entity Name

Exposed Protocols, Primitives, API

Associated RP

Security

Authenticator ASN GW Auth Relay Primitives R6

Auth Relay BS Auth Relay Primitives R6

Key Distributor ASN GW AK Transfer Primitives

R6

Key Receiver BS AK Transfer Primitives

R6


Page - 36


Function Categories

Function ASN Entity Name

Exposed Protocols, Primitives, API

Associated RP

IntraASN

Mobility

Data Path Function

(Type 1)

ASN GW & BS Data Path Control Primitives R6

Handover Fn ASN GW & BS HO Control Primitives R6

Context Server & Client

ASN GW & BS R6

L3 Mobility MIP FA ASN GW Client MIP R6

MIP AR ASN-GW Client MIP R6

Radio Resource

Management

RRC BS RRM Primitives R6

RRA BS None (BS internal) -

RRC Relay ASN GW RRM Primitives R6

Paging Paging Agent BS Paging & Idle Mode Primitives R6

Paging Controller ASN GW Paging & Idle Mode Primitives R6

QoS SFA ASN GW QoS Primitives R6

SFM BS

1

6.4 Core to Access Network Internetworking Relationships 2

The following figures illustrate several internetworking relationships between ASN and CSN for 3

o sharing an ASN by multiple CSNs, 4

o providing service to roaming MS with mobility anchor in the visited CSN, 5

o providing service to roaming MS with mobility anchor in the home CSN, 6

o providing a stationary service without inter-ASN mobility and, 7

o enabling service acces s i n t he Client M IP6 cas e o ver the C oA a s well a s o ver t he H oA a nd e nabling 8 services in the Client MIP4 case over HoA. 9

o Enabling service access in the Proxy MIP6 case 10

o ASN an d C SN ar e co mbined, pr oviding S imple I P s ervice t o n on-roaming M S out of A SNs di rectly 11 attached to a CSN 12

o ASN and CSN are combined, with roaming , providing Simple IP service to a roaming MS out of the V-13 CSN 14

o ASN and CSN are combined, with roaming , providing Simple IP service to a roaming MS out of the H-15 CSN 16

o ASN and CSN are split, providing Simple IP service to non-roaming MS out of ASNs connected by a static 17 link to the CSN 18

o ASN and CSN are split, with roaming, IP service provided by Simple IP session anchored at V-CSN case 19


Page - 37


o ASN and CSN are split, with roaming, IP service provided by Simple IP session anchored at H-CSN case 1

o providing Simple Ethernet services out of a combined ASN and CSN without roaming 2

o providing Simple Ethernet services with split ASN and CSN without roaming 3

o providing Simple Ethernet services out of a combined ASN and CSN with roaming 4

o co-existence of Simple Ethernet and MIP-based Ethernet services with IP services (Simple IP and/or MIP) 5 within the same access network 6

o switched Ethernet WiMAX access scenario 7

ASN decomposition is only shown as example for illustrative purposes. 8

6.4.1 NAP Sharing 9 Several ASNs might be connected to a s ingle CSN and vice-versa i.e., several CSNs might share the same ASN. 10 Figure 6-4 depicts an instance of ASN-CSN inter-connection wherein multiple CSNs share the same group of ASNs. 11 In t his s cenario, ASN a nd MS will e xchange i nformation s o t hat t he ASN c an d etermine which C SN a M S 12 SHOULD be connected to. ASN and CSN may be owned by the same operator or may belong to different operators. 13

The case where multiple operators share the same ASN constitutes an example of unbundled access networking. 14

R 3

R 2

R 1

ASN

ASN CSN

NAP NSP

MS

BS

BS

BS

BS

ASNGW

AAA

AAA

HA/LMA

PF

PF

Internet R 4

R 2

MS

R 3

ASNGW

R 3R 1CSN

HA/LMA

15

Figure 6-4 - Multiple ASN to Multiple CSN Connectivity 16


Page - 38


6.4.2 Roaming with HA located in the visited NSP 1 The Figure 6-5 shows the reference architecture for providing service to roaming MS with usage of the HA in the 2 visited CSN. Authentication, authorization as well a s policy in formation are provided from the home CSN to the 3 visited CSN over the reference point R5. Accounting information is forwarded from the visited CSN to the home 4 CSN over R5, and access to services in the home CSN may also provided over R5 whereas Internet access is usually 5 established directly out of the visited CSN. 6

R2

ASN

CSN

CSN

NAP

ASN

Internet

R1 R3

R4

R3

R5

H-NSPV-NSP

MS

BS

BS

ASNGW

BS

BS

ASNGW

AAAProxy

HA/LMA

PFPF

H-AAA

7

Figure 6-5 - Roaming model with HA in visited NSP 8


Page - 39


6.4.3 Roaming with HA located in the home NSP 1 The Figure 6-6 shows the reference architecture for providing service to roaming MS with usage of the HA in the 2 home CSN. 3

Note for example: R3 signaling for Mobile IP may go directly to the H-NSP bypassing the V-NSP. 4

ASN

CSNAAAProxy

HA/LMA

PF

NAP

BS

BS

ASNGW

PF

CSNH-AAA

ASN

Internet

R3

R2

R1

R4R5

V-NSP H-NSP

MS

BS

BS

ASNGW

5

Figure 6-6 - Roaming model with HA in home NSP 6


Page - 40


6.4.4 Stationary Network 1 When CSN-anchored mobility management is not required and a s ingle ASN i s connected with a s ingle CSN the 2 reference point R3 may not to be exposed. In this case it is possible to attach directly the CSN to the ASN and 3 remove in t he combined ASN/CSN a ll the functions not being visible o n any o f the r emaining r eference points. 4 When serving terminals without Mobile IP support, even the FA and the HA can be removed in the model, as these 5 entities do not have any impact on any of the remaining reference points. 6

Such a simplified model is well suitable for stationary applications, as there is no need for Mobile IP based mobility 7 management. Figure 6-7 shows the derived stationary network reference model with support for roaming MS. For 8 roaming MS the authentication, authorization, accounting and policy control are provided by the home NSP over the 9 reference point R5. 10

R2

R1 AAAproxy

HA/LMA

PF

NAP + NSP H-NSP

R5PF

CSNH-AAA

ASN CSN

Internet

MS BS

BS

ASNGW

11

Figure 6-7 - Stationary network model 12


Page - 41


6.4.5 Client MIP6 network with service connectivity on the CoA as well as on the HoA 1 Terminals w ith Client M IP6 have b een as signed t wo ad dresses: t he C are-of-Address ( CoA) for e stablishing t he 2 transport connection to the HA, and the Home Address (HoA) for providing mobile service connectivity by the HA 3 in the home CSN. In addition to the mobile services over the HoA, the CoA can be used for stationary access to 4 services and for route optimization between mobile terminals. Making use of the CoA for access to services requires 5 the extension of the ASN to stationary network by directly attaching a CSN to the ASN to provide all the necessary 6 control for service access. While route optimization and stationary services are provided by the directly attached 7 CSN, mobile I Pv6 r uns ov er R 2 f rom the M S t o t he HA i n t he home N SP. A uthentication, a uthorization a nd 8 accounting information as well as policy control are handled by the home NSP over an R5 reference point. 9

Figure 6-8 shows t he network r eference model for c lient M obile I Pv6 with s upport of r oute opt imization a nd 10 stationary services on the CoA. 11

(ASN-GW)

GwyRtr HA

R5

V-CSN

H-AAA

H-CSN

Internet

MS BS

BS

AR

ASNHoA

CoA

12

Figure 6-8 - Mobile IPv6 with service over CoA and HoA 13

14

6.4.6 Simple IP Networks Scenarios 15 In a S imple IP network the ASN may be either directly attached to the CSN or split from the CSN. T he data path 16 between ASN and CSN is statically pre-configured and is outside the scope of this specification. Section 6.4.6.1 17 shows a combined ASN with CSN model without roaming. Section 6.4.6.2 and Section 6.4.6.3 show combined ASN 18 with CSN model with roaming and Simple IP session anchored at either V-CSN or H-CSN cases. Alternatively, the 19 ASN will provide DHCP proxy functionality. 20

Section 6.4.6.4 shows ASN and CSN are split and without roaming case. Section 6.4.6.5 shows ASN and CSN are 21 split, with roaming, and Simple IP session anchored at V-CSN case. Session 6.4.6.6 shows ASN and CSN are split, 22 with roaming, and Simple IP session anchored at H-CSN case. Access Router and Core Router functional entities 23 are used to connect the ASN and the CSN to establish data plane. The point-of-attachment address and connectivity 24 to the Internet is through the CSN. CSN will provide the DHCP server for IP address assignment. Internet access is 25 provided through the CSN. 26

27


Page - 42


6.4.6.1 ASN and CSN combined, no roaming in Simple IP case 1 This i s S imple IP standalone deployment s cenario. In this case, NAP an d NSP are co mbined an d with t he same 2 operator. No roaming to other NSPs, IP service is provided through NSP. No R3 and R5 are exposed. 3

Due t o p ublic I Pv4 ad dress ex haustion i ssues, o perators may h ave t o p lace a N AT d evice(s) b etween t heir 4 subscribers and the public Internet. This would allow public IPv4 addresses to be shared by many subscribers. 5

When a Large Scale NAT (LSN) is used, it is co-located with Core Router (CR) in CSN. 6

NOTE: The purpose of the Large Scale NAT (LSN) is to handle private IPv4 addresses allocated to MS. IPv6 and 7 public IPv4 addresses do n ot require a LSN. It should also be noted for purposes of this document LSN and CGN 8 (Carrier Grade NAT) are synonymous. 9

R1ASN

NAP+NSP

MS

BS

BSGWAR

DHCPRelay/Proxy

CSN

CR/LSN

DHCPServer

Internet

R2

BS

BS

R4

ASNGWAR

DHCPRelay/Proxy

PF

AAA

10

Figure 6-9 - Simple IP combined ASN and CSN standalone 11


Page - 43


6.4.6.2 ASN and CSN combined, with roaming, Simple IP session anchored at V-CSN case, No 1 R5 bearer plane exists 2

In this Simple IP deployment scenario, NAP and V-NSP is the same operator. H-NSP has roaming agreement with 3 V-NSP. Simple IP session is anchored through V-CSN. R3 interface is not exposed; R5 control plane is between V-4 CSN and H-CSN and Internet connectivity is provided at the V-CSN. There is no R5 bearer plane. 5

NAP+V-NSP

R1V-CSN

CR

H-CSN

H-NSP

H - AAA

R2

DHCPServer

R5

R4

Internet / ASP network

BS

BSASNGWAR

DHCPRelay/Proxy

BS

BSASNGWAR

DHCPRelay/Proxy

MS

PF

AAA-Proxy

PF

6

Figure 6-10 - Simple IP combined ASN and CSN, roaming, anchored at V-CSN 7


Page - 44


6.4.6.3 ASN and CSN combined, with roaming, Simple IP anchored at H-CSN case 1 Simple I P s ession i s a nchored t hrough H -CSN an d I nternet co nnectivity i s p rovided at t he H -CSN. R3 i s not 2 exposed. R5 data and control plane is between V-CSN and H-CSN. 3

NAP+V-NSP

R1V-CSN H-CSN

H-NSP

R2

DHCPServer

R5

R4


BS

BSASNGWAR

DHCPRelay/Proxy

BS

BSASNGWAR

DHCPRelay/Proxy

MS

PF

AAA-Proxy CR

PF

AAA

4

Figure 6-11 - Simple IP combined ASN and CSN, roaming, anchored at H-CSN 5


Page - 45


6.4.6.4 ASN and CSN Split, without roaming in Simple IP case 1 In this Simple IP deployment scenario, NAP and NSP are distinct entities with a connection in between. IP service 2 to the MS is provided by the NSP. R3 data plane and R3 control plane functions required for data plane setup are out 3 of scope. 4

NAP

R1H-CSN

NSP

R2

DHCPServerR4


BS

BSASNGWAR

DHCPRelay/Proxy

BS

BSASNGWAR

DHCPRelay/Proxy

MS

CR

PF

AAA

R3

5

Figure 6-12 - Simple IP split ASN and CSN, none roaming 6


Page - 46


6.4.6.5 ASN and CSN Split, with roaming, Simple IP session in V-CSN case 1 In t his S imple I P d eployment scenario, N AP a nd V -NSP i s n ot t he s ame o perator. T he H -NSP has r oaming 2 agreement with V-NSP. Simple IP session and connected to the Internet / ASP through V-CSN. 3

In this case, both R3 and R5 control plane are exposed. R3 bearer plane and R3 control plane required for bearer 4 plane setup are out of scope for WiMAX Forum® Network Architecture, no R5 bearer plane exists. 5

V-NSPNAP

R1V-CSN

CR

H-CSN

H-NSP

H-AAA DHCPServer

R5

R4


BS

BSASNGWAR

DHCPRelay/Proxy

BS

BSASNGWAR

DHCPRelay/Proxy

MS

PF

AAA-Proxy

PF

R3

R2

6

Figure 6-13 - Simple IP split ASN and CSN, roaming, anchored at V-CSN 7


Page - 47


6.4.6.6 ASN and CSN Split, with roaming, Simple IP session in H-CSN case 1 In t his S imple I P d eployment scenario, N AP a nd V -NSP i s n ot t he s ame o perator. T he H -NSP has r oaming 2 agreement with V-NSP. Simple IP session is anchored through H-CSN and Internet connectivity is provided at V-3 CSN. 4

In this case, both R3 and R5 control plane are exposed. R3 and R5 bearer plane are out of scope from WiMAX 5 Forum® Network Architecture specification, Also R3, R5 control plane required for bearer plane are out of scope. 6

V-NSPNAP

R1V-CSN H-CSN

H-NSP

H-AAA

DHCPServer

R5

R4


BS

BSASNGWAR

DHCPRelay/Proxy

BS

BSASNGWAR

DHCPRelay/Proxy

MS

PF

AAA-Proxy

PF

R3

R2

CR

7

Figure 6-14 - Simple IP split ASN and CSN, roaming, anchored at H-CSN 8

6.4.7 Simple Ethernet Networks 9 Like in the case for Simple IP, Simple Ethernet comprises a number of different network configurations: 10

1) ASN and CSN are combined without roaming, 11

2) ASN and CSN are combined with roaming and Ethernet service anchored at the V-CSN, 12

3) ASN and CSN are combined with roaming and Ethernet services anchored at the H-CSN, 13

4) ASN and CSN are split, without roaming, 14

5) ASN and CSN are split with roaming and Ethernet services anchored at the V-CSN, and 15

6) ASN and CSN are split with roaming and Ethernet services anchored at the H-CSN. 16

Similar to Simple IP, the details of the statically configured data path protocol of R3 and R5 for Simple Ethernet is 17 out of scope of this document. 18

Instead of connecting directly to the access router in the IP services case, a b ridge is deployed in the CSN i n the 19 Ethernet services case for forwarding the Ethernet frames either to the MSs on the radio side or to another CSN or 20 Ethernet service providers on the network side. The bridge in the CSN provides a dedicated bridge port for each of 21 the MS anchored at the CSN. 22


Page - 48


Figure 6-15 shows the Simple Ethernet configuration with combined ASN and CSN without roaming. 1

R1MS

NAP + NSP

BS

ASNBS

ASPproviding Ethernet Service

AAAServer

CSN

PF

R2

R6ETH

ServiceCore

Bridge

ASN GW

2

Figure 6-15 - Simple Ethernet – Combined ASN-CSN, No Roaming 3

Figure 6-16 shows t he Simple E thernet c onfiguration with ASN a nd CSN split without r oaming. Forwarding o f 4 Ethernet frames between ASN and CSN, and CSN and Ethernet ASP is usually not performed by MAC addresses 5 but b y s ome s ervice p rovider t ag u sed b y t he selected t unneling mechanism, s uch as 8 02.1ad, 8 02.1ah, G RE o r 6 MPLS. T he t ag i s used t o d enote a p articular M S ( E-Line s ervice) o r a g roup o f M Ss ( E-LAN service). T he 7 tunneling mechanism is based on agreement between operators and is out of scope of this document. 8

R1MS

NAP

BS

ASNBS


NSP

AAAServer

CSN

R3

PF

R2

R6ETH

ServiceCore

Bridge

ASN GW

9

Figure 6-16 - Simple Ethernet – Split ASN-CSN, Without roaming 10

Figure 6-17 shows the deployment scenario with an (Ethernet) MS attached to a foreign access network for Simple 11 Ethernet in the case where ASN and CSN are combined with roaming and Ethernet services are provided through 12 the H-CSN. AAA and PF information as well as the datapath are provided from the home NSP to the visited NSP 13 over R 5. T he br idge i n t he visited C SN forwards E thernet f rames co ming from t he MS t o t he h ome N SP, an d 14 Ethernet frames coming from the home NSP to the particular MS. 15

Forwarding of Ethernet frames between the ASN, V-CSN, H-CSN, and Ethernet ASP is usually not performed by 16 MAC addresses b ut b y s ome s ervice p rovider t ag u sed b y t he selected t unneling mechanism, s uch a s 8 02.1ad, 17 802.1ah, GRE or MPLS. The tag is used to denote a particular MS or a group of MS. The tunneling mechanism is 18 based on agreement between operators and is out of scope of this document. 19


Page - 49


R1MS


H-NSP

H-AAACSN

PF

R2

ETHService

CoreBridge

NAP + NSP

BS

ASNBS AAA

Proxy

CSN

PF

R6ETH

ServiceCore

Bridge

ASN GW

R5

1

Figure 6-17 - Simple Ethernet – Combined ASN-CSN with roaming 2

6.4.8 MIP-based Ethernet 3 MIP-based Ethernet deploys Mobile IP to provide dynamic tunnel setup on R3 to realize wide area nomadicity and 4 mobility of Ethernet services terminals. The control path as well as the data path of the R3 interface is fully specified 5 to enable dynamic establishment of Ethernet connectivity into the core network. 6


Page - 50


6.4.9 Co-existence of Simple Ethernet and MIP-based Ethernet services with IP services 1 The s ame ASN may be us ed by multiple N SPs f or pr oviding I P-Services as well a s E thernet Services. T he 2 following figure shows the NRM configuration for deploying the same ASN for Ethernet Services (Simple Ethernet 3 and MIP-based Ethernet) as well as IP Services. 4

R1MS

NAP

BS

ASNBS


NSP

AAAServer

CSN

R3

PF

R2

R6ETH

ServiceCore

Bridge

ASN GW

BS

ASNBS AAA

Server

CSN

R3

PF

R6 CRASN GW Internet

R4

5

Figure 6-18 - Coexistence of IP Services and ETH Services 6

While mobility for E thernet services may not be r equired in this case, de ployment of R3 b y the CSN providing 7 connectivity to E thernet services al lows for sharing the same access network with CSNs providing IP services as 8 well as extending the coverage ar ea for Ethernet s ervices o ver multiple ASNs p otentially belonging to multiple 9 NAPs for a nomadic kind of access. 10

A s ingle A SN m ay be enabled t o d eliver M IP-based E thernet s ervices as well as Simple E thernet s ervices in 11 addition to Mobile IP services as well as Simple IP services. 12


Page - 51


6.4.10 Switched Ethernet WiMAX® access network scenario 1 The Network Reference Model and in particular the Simple IP/ETH network models also provide the foundation for 2 interoperable implementations o f WiMAX® access networks i n which E thernet a ggregation i s used i nstead o f IP-3 based tunnels for the data paths between the ASNs and the CSN. Such an realization of the WiMAX access network 4 is feasible for providing stationary services. 5

Integrated ASNs allow the deployment of Ethernet aggregation throughout the radio access infrastructure. 6

MS AAA

PF

R1Integrated

ASNCSN

R2 NAP

Bridge

Integrated

ASN

Integrated

ASN

ASN

NSP

AAA

PF

CSN

NAP

Integrated

ASN

NSP

Integrated

ASN

Integrated

ASN

Integrated

ASN

BridgeASP

Providing EthernetService

R3

7

Figure 6-19 - Switched Ethernet access network 8

The I ntegrated ASNs a re c onnected o n t he network s ide t o t he C SN via a n E thernet a ggregation network f or 9 concentration an d forwarding of t he d ata path. The IP-based co ntrol p lane between the I ntegrated A SNs an d the 10 CSN is also carried over the Ethernet aggregation network. In this network scenario there is no interconnection as 11 well as intercommunication between the Integrated ASNs across R4. 12

According to the definition of the Simple IP/ETH network models, the particular Ethernet protocol for the R3 data 13 path is not specified and depends on the kind of services provided by the CSN to the SSs/MSs. Network operators 14 may choose their favorite solution depending on the requirements and the available network infrastructure. 15

The R3 control protocol according to the Simple IP/ETH network model is used between the CSN and the Integrated 16 ASNs. 17

6.4.11 Proxy MIP6 network with service connectivity on the HoA 18 In P MIP6 s upported network, i n order to provide the I P mobility s ervice connectivity to M S that doe s not have 19 mobility c apability, LMA in C SN will as sign a h ome p refix o r an I Pv4 M N-HoA to th e M S ( if n ot s tatically 20 allocated from the AAA server). Depending on the network configuration, the home prefix(es) could be assigned by 21 either V-LMA (if VCSN exists) or H-LMA. Authentication, authorization and accounting information as well as 22 policy control are handled by the home NSP over R3 and/or R5 reference points. 23

Figure 6-20 shows the network reference model for Proxy Mobile IPv6 with LMA in VCSN and Figure 6-21 shows 24 network reference model when PMIP6 LMA is anchored in the HCSN. 25


Page - 52


ASN H-CSN

V-AAA

LMA

V-CSN

H-AAA

Internet

R3

(MN-HoA)

R5

MSBS

BS

AR/MAG

(Proxy-CoA)

1

Figure 6-20 - Proxy Mobile IPv6 through V-CSN with service over HoA 2

3

ASN

H-CSN

V-AAA

LMA

V-CSNH-AAA

Internet

R3(MN-HoA)

R5

MSBS

BS

AR/MAG

(Proxy-CoA)

4

Figure 6-21 - Proxy Mobile IPv6 through H-CSN with service over HoA 5

6


Page - 53


6.5 CSN Reference Model 1

CSN internal reference points are out of scope of this specification. 2

3


Page - 54


7. Functional Design and Decomposition 1 Unless s pecified o therwise, call f lows a nd messages d efined i n t his s ection ar e s uperseded b y co rresponding 2 definitions in Stage 3. 3

Note: See § 3.0 R eferences i n WiMAX F orum® Network A rchitecture [ Part 1 ] for references ci ted i n t his 4 document. 5

7.1 Network Entry Discovery and Selection/Re-selection 6

7.1.1 Functional Requirements 7 a) The s olution ar chitecture S HALL acco mmodate N omadic, P ortable, an d f ully mobile d eployment 8

scenarios. 9

b) The solution architecture SHALL accommodate “NAP sharing” and “NAP+NSP” deployment models. 10

c) The solution architecture SHOULD support Licensed and License-Exempt (LE) deployments. 11

d) The solution architecture SHOULD support both manual 1 and automatic 2

7.1.2 Use Case Scenarios 13

NSP selection. 12

NSP discovery and selection procedures are typically executed on a first time use, initial network entry, network re-14 entry, or when an MS transitions across NAP coverage areas. This subsection describes all four use case scenarios. 15

7.1.2.1 Use-case Scenario 1 - First-Time Use without NAP/NSP Configuration Information Stored 16 on MS 17

a) MS detects one or more available WiMAX® NAPs. 18

b) MS discovers available NSPs associated with one or more NAPs. 19

c) MS identifies all accessible NSPs and selects an NAP and an NSP based on some preference criteria. 20

d) MS performs more concrete processes procedure with a NAP. 21

e) MS becomes authorized on the selected NSP for service subscription purposes only to create a business 22 relationship with the selected NSP. 23

f) MS creates a business relationship enabling access via the selected NSP. 24

g) MS acquires and stores the configuration information. 25

7.1.2.2 Use-case Scenario 2 - Initial Network Entry or First-Time Use with NAP/NSP 26 Configuration Information 27

a) MS detects, using the stored configuration information, one or more available WiMAX NAPs. 28

b) MS discovers available NSPs associated with one or more NAPs. 29

c) MS id entifies a ll a ccessible N SPs a nd, u sing t he s tored c onfiguration i nformation, selects o r a llows a 30 subscriber to select an NSP based on some preference criteria. 31

d) MS performs initial network entry procedure with a N AP that has a b usiness relationship enabling access 32 via the selected NSP. 33

1 In manual selection, the user must be able to receive the information about all available NSPs, and indicate its NSP preference to the network manually. 2 In automatic selection, the MS will automatically make the NSP selection decision based on the detected wireless environment and configuration file information without the user’s intervention.


Page - 55


In case of failure, MS reverts to Use Case Scenario 1. 1

7.1.2.3 Use-case Scenario 3 - Network Re-entry 2 Network r e-entry is equivalent to establishing connection with the same or another BS in a p reviously discovered 3 WiMAX N AP. S cenario 3 mechanics as sumes t hat N AP an d N SP g eographic co verage ar e s ynonymous i n t his 4 context. 5

In case of failure, MS reverts to scenario 2. 6

7.1.2.4 Use-case Scenario 4 - MS Transitions Across NAP Coverage Areas 7 a) MS has previously completed network entry and is in normal operation with its NSP on a WiMAX NAP. 8

b) MS d iscovers, using t he stored co nfiguration i nformation, o ne o r more av ailable ne ighboring W iMAX 9 NAP(s)3

c) MS d iscovers NSPs as sociated with o ne o r more NAPs, which M AY include i ts cu rrently a uthorized 11 NSP3. 12

. 10

d) Due to user movement or other confounding factor, MS elects to transition to another NAP. 13

e) MS identifies all accessible NSPs and, using the stored configuration information, selects an NSP based on 14 some preference criteria. 15

f) MS performs network re-entry with a NAP that has a business relationship enabling access via the selected 16 NSP. This network re-entry will involve a full authentication. Optimized handover on all other network re-17 entry steps is not possible. 18

In case of failure, MS reverts to scenario 2. 19

7.1.3 NAP, NSP Domains 20 The a dopted WiMAX F orum® Network A rchitecture reference model e nables d eployments wherein a n M S may 21 encounter one or more of the following situations: 22

a) An Access Service Network (ASN) managed/owned by a single NSP administrative domain (also referred 23 to as “NAP+NSP” deployment case). 24

b) An ASN managed b y a N AP b ut s hared b y t wo o r more N SPs ( also r eferred t o as “ NAP sharing” 25 deployment case). 26

c) A physical geographic region covered by two or more ASNs, representing either a “NAP+NSP” or “NAP 27 sharing” scenario. 28

NOTE: “NAP sharing” is referred to the ASN deployment scenario when it has the management plane, control plane 29 and d ata p lane co nnectivity shared d irectly with more t han o ne N SP i .e., this is n ot th e s ame a s th e r oaming 30 scenario, where multiple NSPs may be accessible via the ASN, but are accessible indirectly through one (or more) 31 of the NSPs attached to that specific ASN. 32

The r equirement i s to en able t he M S t o d iscover al l acce ssible N SPs, an d t o i ndicate the N SP s election d uring 33 connectivity to t he ASN. T he act ual N SP selection mechanism e mployed b y t he MS may b e b ased o n various 34 preference cr iteria, p ossibly depending o n t he pr esence o n t he M S of c onfiguration i nformation. Configuration 35 information SHALL include: 36

a) information useful in MS discovery of NAP including channel, center frequency, and PHY profile, 37

b) information u seful in M S d ecision mechanism to d iscriminate a nd p rioritize N SPs f or service selection 38 including a list of authorized NAP(s) and a list of authorized NSP(s) with a method of prioritization for the 39 purpose of automatic selection, 40

3 Steps b and c of Scenario 4 may occur either before or after step 4 without affecting performance.


Page - 56


c) a list of authorized ‘share’ or ‘roaming’ affiliation relationships between authorized NAP(s) and NSP(s) 1 and partner NAP(s) and NSP(s), with a method of prioritization for the purpose of automatic selection, 2

d) identity/credentials provided by NSP(s) to which the MS has a business relationship, and 3

e) the mapping relation table between 24-bit NSP identities and corresponding realms of the NSPs. 4

Configuration i nformation may be pr ovided on a pr e-provisioned b asis o r at t ime of M S d ynamic s ervice 5 subscription and may be subject to periodic update in a method outside the scope of this standard. 6

ASN ofNAP_6

CSN ofNSP_1

CSN ofNSP_2

CSN ofNSP_3MS_1

of NSP_1

ASN ofNAP_4

CSN ofNSP_4

MS_2 ofNSP_4

7

Figure 7-1 - Coverage Area with Overlapping ASNs 8

For e xample, a s shown i n Figure 7-1, M S_1 an d MS _2 d iscover av ailable N SPs an d s elect o ne b ased o n i ts 9 configuration information. M ore specifically, MS_1 prefers to connect to ASN of “NAP_6” because it is directly 10 affiliated with M S_1’s home N SP th rough NAP sharing. A nd, M S_2 pr efers t o c onnect t o A SN of “NAP_4” 11 because it is owned by MS_2’s home NSP (i.e., NSP_4). 12

There is a need for a solution framework that enables an MS to discover identities of available NSP(s) in a WiMAX 13 coverage area, and indicate i ts selected NSP to the ASN. While the general method for MS selection o f NSP for 14 attachment is provided as part of this release, the specific mechanisms that an MS MAY use to select a p articular 15 NSP f rom t he l ist of di scovered N SPs a re ou t of s cope of this r elease, b ut would l ikely i nclude r eference t o 16 configuration information. 17

7.1.4 NAP, NSP Discovery and Selection 18 This subsection provides an overview of a solution for NAP, NSP discovery and selection. 19

The solution consists of four procedures: 20

a) NAP Discovery 21

b) NSP Discovery 22

c) NSP Enumeration and Selection 23

d) ASN Attachment 24


Page - 57


WiMAX® NAP D iscovery refers t o a process w herein a n MS d iscovers av ailable N AP(s) i n a d etected wireless 1 coverage area. NSP Access Discovery refers to a p rocess wherein an MS discovers available NSP(s) in a co verage 2 area. NSP Enumeration and Selection refers to a process of choosing the most preferred NSP and a candidate set of 3 ASNs to attach, based on the dynamic information obtained during the discovery phase and stored configuration 4 information. ASN At tachment based on NSP Enumeration and selection refers to a process wherein the MS indicates 5 its selection during registration a t ASN associated with the selected NSP by providing its identity ( in the form o f 6 NAI [60]). The enumerated steps are not sequential and need not be completed in their entirety. That is, NSP Access 7 Discovery and NSP Enumeration and Selection MAY well occur concurrent to WiMAX N AP Discovery. Also, there 8 is no requirement that an MS discover all NAPs and NSPs in the available environment. An MS MAY stop the 9 discovery p rocess o n d iscovery o f a N AP and NSP meeting the MS NSP Enumeration a nd Selection criteria and 10 proceed to ASN At tachment. 11

7.1.4.1 WiMAX® NAP Discovery 12 An MS detects available NAP(s) by scanning and decoding DL-MAP of ASN(s) on detected channel(s). The 24-bit 13 value of the “operator ID” (see 6.3.2.3.2 of IEEE Std 802.16) within the “Base Station ID” parameter in the DL-14 MAP me ssage i s t he N AP I dentifier and is used t o i ndicate t he o wnership o f t he ASN. T he va lue o f t he 2 4-bit 15 “operator ID” shall be assigned as an IEEE Std 802.16 Operator ID by the IEEE Registration Authority4

7.1.4.2 NSP Access Discovery 20

. Operator 16 ID/NAP I D a llocation a nd administration method, a nd field formatting a re de fined i n I EEE Std 802. 16. I f 17 information useful in MS di scovery of NAP is available in configuration information, i t may be used to improve 18 efficiency of NAP discovery. 19

The NAP SHALL be served by one or more NSPs. In NSP discovery, an NSP identifier can be presented to the MS 21 as a u nique 24 -bit NSP identifier. T he value of the 24 -bit NSP ID (i.e., NSP Identifier) SHALL be issued as an 22 IEEE Std 802.16 Operator ID by the IEEE Registration Authority4. As both NAP ID and NSP ID are allocated from 23 the s ame number s pace, t he numbers ar e g uaranteed t o b e u nique i n b oth d omains. NSP I D i s ei ther a 2 2-bit 24 globally-assigned ID or a co mbined MCC+MNC as described in ITU-T Recommendation E.212. Selection of the 25 method used for NSP ID format is implementation specific. 26

During scanning, i f the MS cannot deduce available NSP(s) from the NAP identifier based on the NSP Identifier 27 Flag, detected NAP IDs, and the configuration information, then it SHOULD try to dynamically discover a lis t of 28 NSPs supported by the NAP. 29

If t he NAP and N SP ar e the same (i.e., there is a one-to-one relationship between t hese I Ds), t he N AP S HALL 30 identify this case by setting the least significant 1st bit (1st LSB; the 25th bit of Base Station ID; the NSP Identifier 31 Flag) of the Base Station ID to a value of ‘0’. For this case, the MS SHALL assume that the NSP ID is the same ID 32 presented as NAP ID. 33

In t he ev ent t hat more t han o ne N SP i s s erved b y a d etected N AP, o r t hat s ome regulatory o r d eployment 34 requirement compels separate presentation of one or more NSP IDs, the NAP shall identify this case by setting the 35 NSP Identifier Flag to a value of ‘1’. 36

Independently of NSP Identifier Flag value, the NAP MAY transmit the NSP ID list and Verbose NSP Name List as 37 part of the Service Information Identity (SII-ADV) broadcast MAC management message. Also, the BS SHALL 38 transmit the l ist o f NSP IDs and Verbose NSP Names as part of SBC-RSP in response to an MS request through 39 SBC-REQ. 40

In this phase, if the list of NSP identifiers supported by a NAP does not exist in the configuration information of the 41 MS, or the list of NSP identifiers supported by a NAP is changed, e.g. the optional NSP Change Count TLV (NSP 42 Change Count TLV is described in the IEEE Std 802.16) obtained from the network as part of obtaining the NSP ID 43 list, is different with that stored in the configuration information of the MS, the MS SHOULD get the list from the 44 network. O therwise, a vailable N SP(s) as sociated with a N AP S HALL b e en umerated l ocally b ased o n t he 45 configuration information of the MS. 46 4 The IEEE Registration Authority is a committee of the IEEE Standards Association Board of Governors. General information as well as details on the allocation of 802.16 Operator IDs can be obtained at http://standards.ieee.org/regauth.


Page - 58


24-bit NSP identities received in this phase SHALL be mapped into realms of corresponding NSPs. 1

7.1.4.3 NSP Enumeration and Selection 2 For automatic selection, an MS makes its NSP selection decision based on the dynamic information obtained within 3 a co verage ar ea ( e.g., a l ist o f av ailable N SP I dentifiers offering services), an d co nfiguration i nformation. T he 4 specific algorithms that an MS MAY use to select the most preferred NSP from the list of discovered NSPs are out 5 of scope of this release. 6

For manual selection, the user manually selects the most preferred NSP based on the dynamic information obtained 7 within t he co verage ar ea. Man ual selection ca n al so en able u se s cenarios where a n on-subscribed u ser wants to 8 connect t o a d etected network. F or example, t he u ser wants to ex ercise a n i nitial p rovisioning p rocedure with a 9 specific NSP, or it wants to use the network on “pay for use” basis. 10

7.1.4.4 ASN Attachment Based on NSP selection 11 Following a decision to select an NSP, an MS indicates its NSP selection by attaching to an ASN associated with the 12 selected NSP, and by p roviding i ts identity and home NSP domain in the form o f NAI. The ASN uses the realm 13 portion of the NAI to determine the next AAA hop to where the MS’s AAA packets SHOULD be routed. The MS 14 SHALL use its NAI with additional information (also known as decorated NAI - described in section 2.7 of [48]) to 15 influence t he r outing c hoice o f t he next AAA ho p when t he home N SP r ealm i s o nly r eachable via a nother 16 mediating realm (e.g., a visited NSP). For example, as shown in Figure 7-2, MS_1 uses a normal/root NAI (i.e., 17 user-name@NSP_1.com) as the AAA packets can be directly routed to the AAA server in NSP_1. Whereas, MS_2 18 needs to construct a d ecorated NAI (e.g., NSP_4!user-name @NSP_1.com) as the AAA packets cannot directly be 19 routed to the home NSP (i.e., NSP_4). The specific use of realm is defined in section 7.3.7. 20

MS_1 ofNSP_1

MS_2 ofNSP_4

CSN ofNSP_2

CSN ofNSP_3

CSN ofNSP_1

CSN ofNSP_4

ASN ofNAP_1

NAP Sharing

21

Figure 7-2 - Deployment example with NAP sharing 22

7.2 IP Addressing 23

This section defines IP addressing for both IPv4 and IPv6 protocols. IPv4 addressing details are described in Stage 2 24 section 7.2.1 and IPv6 addressing details are described in Stage 3 section 5.11.8. 25

This section does not apply for end-to-end Ethernet services. 26

7.2.1 IPv4 address Management 27 IP address al location refers to the Point o f Attachment (PoA) address delivered to the MS. The d iscussion below 28 refers primarily to allocation of dynamic IP addresses. From the perspective of the MS, for MS that do not support 29 Client MIP, DHCP [11] is used as the mechanism of dynamic IP address allocation. The home CSN may employ 30 alternate techniques such as IP address assignment by an AAA server and deliver it to the MS via DHCP. Details of 31 such al ternate mechanisms for I P address al location ar e o ut o f s cope o f this r elease. T he f ollowing d iscussion 32 focuses on the usage of DHCP to allocate PoA address to the MS. In the context of this section (and R3 Mobility 33 Management section) PoA address corresponds to the HoA (Home Address). 34


Page - 59


7.2.1.1 Functional Requirements 1 Note - Considerations for overlapping IP addresses in the ASN is beyond the scope of this release. 2

a) When an MS is an IPv4 gateway, a Point-of-Attachment IPv4 address (PoA address) SHALL be allocated 3 to the IPv4 gateway. When MS is an IPv4 host, a PoA IPv4 address SHALL be allocated to the IPv4 host. 4

b) For fixed and nomadic access, the PoA IP address has to be routable in the CSN and ASN and the PoA 5 address SHALL be assigned from the CSN address space. 6 7 For nomadic and mobile access, the PoA address SHALL be dynamically assigned from the address space 8 of CSN of either Home-NSP or Visited NSP depending on: 9

o Roaming agreement between Home NSP and Visited NSP. 10

o User subscription profile and policy in Home NSP. 11

c) For fixed access, the PoA address allocated to MS SHALL be either static or dynamic. 12

d) The allocation of PoA address SHALL NOT preclude allocation of additional tunnel IP address to access 13 specific ap plications ( i.e., i nner t unnel I P ad dress al located f or V PN, et c.).This r equirement is a lso 14 applicable for overlay mobility based on MIP. 15

e) For billable IP services, a Point-of-attachment IP address SHALL be allocated to MS only after successful 16 user/MS a uthorization. T he allocated ad dresses S HALL be b ound t o t he au thorized u ser/MSs for t he 17 duration of the session. The binding MAY be maintained by an Address Allocation Server (e.g., a D HCP 18 server or AAA server). 19

f) For mobile access (Proxy MIP and Client MIP), a P oA address (MIP home address, See note15

7.2.1.1.1 Fixed Access Scenario 22

), routable 20 in CSN domain SHALL be allocated to MS. 21

Fixed usage scenario SHALL al low two types of PoA IP address al locations, s tatic or dynamic. In both cases the 23 PoA address SHALL be routable in the CSN: 24

a) Static IP address: static IP addresses SHALL be assigned either by manual provisioning in the MS or via 25 DHCP. 26

b) Dynamic IP address: Dynamic IP address assignment is based on DHCP. The DHCP server SHALL reside 27 in CSN domain that allocates the PoA address. A DHCP relay SHALL exist in the network path to the 28 CSN. 29

The DHCP proxy MAY reside in ASN and retrieves IP host configuration information during access authorization 30 (i.e., during AAA exchange). 31

7.2.1.1.2 Nomadic Access Scenario 32 Nomadic access scenario SHALL be based on dynamic IP address assignment. It SHALL be the default for nomadic 33 access deployment scenarios. Static IP address assignment MAY be used; however details on use of static IP address 34 assignment are beyond the scope of this release. Dynamic IP address assignment SHALL be based on DHCP. The 35 DHCP server SHALL reside in home or visited CSN domains. The DHCP proxy MAY reside in ASN and retrieves 36 IP host configuration information during access authorization (i.e., during AAA exchange). 37

7.2.1.1.3 Mobile Access Scenario 38 PoA IP address assignment SHALL be based on DHCP for Simple IP terminals. The DHCP server resides in CSN 39 domain and a DHCP relay resides in ASN domain. Alternatively, a DHCP proxy MAY reside in ASN, wherein it 40 retrieves IP host configuration information and home address during AAA exchange with home NSP. 41 For CMIP-based mobile SS/MSs, MIP [43] based IP addressing SHALL be used instead of DHCP. 42

5 Note 1: In this case, PoA=HoA.


Page - 60


7.2.1.2 Functional Decomposition 1 As p er W IMAX® reference model, functional d ecomposition f or M S IP ad dress management feature S HALL be 2 done across the following reference points: 3

a) R1 4

b) R3 5

c) R5, if applicable 6

Reference points for PoA IP address are shown in Figure 7-3 and Figure 7-4: 7

• When PoA address is allocated by visited NSP, the Address Allocation Server, located in visited CSN, 8 allocates PoA from its pool of addresses (as per roaming agreement with Home NSP). This case is shown 9 in Figure 7-3. 10

• When PoA address is allocated by Home NSP, the Address Allocation Server, located in Home CSN, 11 allocates PoA from its pool of addresses. This case is shown in Figure 7-4. 12

• In addition to the figures below, with the Ethernet case acting as a layer-2 MS, the DHCP client MAY 13 reside in the hosts behind the MS. In this case, the MS simply forwards the DHCP messages between the 14 hosts and Address Allocation Server. 15

SS/MS

ASN R3 CSNR5

R3

NAP + Visited NSP

R1

Note: The DHCP client shown above may reside inside the SS/MS or behind the SS/MS

Home NSP

Authentication& Authorization

ModuleNAS

DHCPClient

DHCPProxy/Relay

AddressAllocation

Server (AAS)

AuthenticationServer/EAP

Server

User Db

CSN

(Credentials/Profiles/Policies)

16

Figure 7-3 - Functional Decomposition for PoA from Visited NSP 17


Page - 61


NAS AAA Proxy

DHCPProxy/Relay

SS/MSS

R1

ASNR3

R3

CSNR5

Home NSPNAP + Visited NSP

Note: DHCP Client shown above may reside inside the SS/MS or behind the SS/MS

CSNAuthentication

Server/EAPServer

User Db(Credentials/

Profiles/Policies)

AddressAllocation

Server (AAS)DHCPClient

1

Figure 7-4 - Functional Decomposition for PoA from Home NSP 2

7.2.1.3 Dynamic IP Configuration Setup for Simple IP in Combined ASN and CSN 3 This section defines the dynamic IP configuration setup for simple IP in combined ASN and CSN network roaming, 4 anchored in vCSN. The dynamic IP configuration setup for CMIP, PMIP when the ASN and the CSN are split, are 5 provided i n s ection 7.8 and for S imple I P in s ection 7.13. The f ollowing s ignaling f low d escribes I P dynamic 6 configuration setup phase using DHCP Proxy/Relay and DHCP server. The placement of DHCP relay and DHCP 7 server in a combined ASN and CSN model is up to local policies. 8

9


Page - 62


7.2.1.3.1 Combined ASN and CSN with DHCP server in CSN 1 The f ollowing s ignaling flow d escribes I P c onfiguration s etup p hase using D HCP r elay a nd D HCP s erver. T he 2 placement of DHCP relay and DHCP server in a combined ASN and CSN model is up to local policies. 3

DHCP server can be located either in Home CSN or Visited CSN. CR is located where the DHCP server is located. 4 The following call flow describes the case where the DHCP server is located in the VCSN. 5

MS BSAR

DHCP relayAuthenticator

2) ISF establishment

1) Access Authentication

3) DHCP DISCOVER

6) DHCP OFFER

DHCP server

Combined ASN and VCSN

7) DHCP REQUEST

10) DHCP ACK

11) User Traffic

AAA

HCSN

CR

4) DHCP DISCOVER

5) DHCP OFFER

8) DHCP REQUEST

9) DHCP ACK

6

Figure 7-5 - IP Configuration phase with DHCP Relay and DHCP Server 7

The essential phases of the process shown in Figure 7-5 appear as follows: 8

1) Access a uthentication: D uring acces s l evel a uthentication, DHCP s erver ad dress i s retrieved f rom t he AAA 9 access authentication or configured locally at the ASN. The relay function in ASN can direct the DHCP messaging 10 to t he s pecific D HCP s erver . The D HCP r elay shall r eceive t he Authorized I P s ervice f rom t he N AS. I f t he 11 Authorized IP service is Simple IP the DHCP relay SHALL not t rigger the PMIP cl ient to initiate a Mo bile IPv4 12 Registration procedure. 13

2) At the completion of authentication, an Initial Service flow (ISF) is established for the MS within the ASN. The 14 ISF can be used for IP configuration of the host. DHCP messages can be transported over the ISF associated with 15 the MS. 16

3–10) IP address assignment and IP Host configuration: After successful establishment of the ISF, the MS sends a 17 DHCP discover message to the DHCP Relay in ASN. The DHCP Relay in ASN manages the DHCP exchange with 18 the DHCP server. In o rder to minimize s ignaling and improve performance, t he network SHOULD send a s ingle 19 DHCP offer message and the DHCP Client SHOULD accept the first DHCP offer it receives. 20

If t he M S r eturns a D HCP d ecline message, t he D HCP c lient a nd server S HOULD b ehave i n co mpliance with 21 RFC2131. The ASN MUST not establish and SHALL release any existing IP session(s) associated with this DHCP 22 transaction. It is an operator/network policy when to initiate Network exit for the MS as specified in section 4.5.2 of 23 [WiMAX Forum® Network Architecture-STG3]. 24

For mobile access, detailed IP address assignment procedures for Proxy MIP and Client MIP are specified in Section 25 7.8.1.8 and Section 7.8.1.9. 26


Page - 63


7.2.1.3.2 Combined ASN and CSN with DHCP proxy in ASN 1 The following signaling flow describes IP configuration setup phase using DHCP proxy in ASN. 2

DHCP Proxy is located in ASN. CR can be located in VCSN or HCSN. The following call flow describes the case 3 where the CR is located in the VCSN. 4

MS BS ARDHCP proxy

2) ISF establishment

1) Access Authentication

3) DHCP DISCOVER

4) DHCP OFFER

CR

Combined ASN and VCSN

5) DHCP REQUEST

6) DHCP ACK

7) User Traffic

AAA

HCSN

5

Figure 7-6 - IP Configuration phase with DHCP Proxy in ASN 6

1) Access authentication: D uring a ccess le vel a uthentication, P oint of Attachment Address of t he gi ven M S is 7 retrieved from the AAA access authentication. The DHCP proxy shall receive the Authorized IP service from the 8 NAS. If the Authorized IP service is Simple IP, the DHCP proxy SHALL not tr igger the PMIP client to initiate a 9 Mobile IPv4 Registration procedure. 10

2) At the completion of authentication, an Initial Service flow (ISF) is established for the MS within the ASN. The 11 ISF can be used for IP configuration of the host. DHCP messages can be transported over the ISF associated with 12 the MS. 13

3–6) IP a ddress a ssignment a nd IP Host configuration: After successful establishment of the ISF, the MS sends a 14 DHCP discover message to the DHCP Proxy in ASN. The DHCP Proxy in ASN manages the DHCP exchange. In 15 order to minimize signaling and improve performance, the network SHOULD send a s ingle DHCP offer message 16 and the DHCP Client SHOULD accept the first DHCP offer it receives. 17

The DHCP Proxy in ASN can return t he co mplete I P configuration t o the MS. In t his case t he IP c onfiguration 18 including the PoA address by the NSP through the access authentication AAA exchange 19

If t he M S r eturns a D HCP d ecline message, t he D HCP c lient a nd server S HOULD b ehave i n co mpliance with 20 RFC2131. The ASN MUST not establish and SHALL release any existing IP session(s) associated with this DHCP 21 transaction. It is an operator/network policy when to initiate Network exit for the MS as specified in section 4.5.2 of 22 [NWG-STG3]. 23


Page - 64


7.2.1.4 IP Address Renewal 1 IP address renewal is initiated by the DHCP client in the MS. 2

The triggers which cause IP address renewal could be based on events such as: 3

- Address lease lifetime expiry threshold reached 4

- Inability to send packets using the address assigned 5

- Indication of network failure 6

- MS specific trigger. 7

DHCP renewal messages are sent directly from the MS to the DHCP server without the need for relaying in the 8 ASN s ince t he MS o btains t he I P ad dress o f t he D HCP s erver f rom the siaddr ad dress field i n t he D HCP A ck 9 message during connection setup time. 10

11

7.2.2 IPv6 12 IPv6 in WiMAX® can be operated in multiple ways. The packet convergence sublayer (CS) specified in the IEEE 13 Std 802.16d/e is used for transport of all packet based protocols such as Internet protocol, IEEE Std 802.3/Ethernet 14 and, IEEE Std 802.1Q. IPv6 can be run over the IP specific part of the packet CS or alternatively over the Ethernet 15 (802.3/802.1Q) specific part of the packet CS. The operation of IPv6 over the IP specific part of the Packet CS is 16 specified in [RFC 5121] and should be referred to for understanding the basic mechanism. This section provides 17 additional information about IPv6 operation that is WiMAX specific. IPv6 over 802.3 and 802.1Q specific parts of 18 the packet CS are described in [REF draft-ietf-16ng-ip-over-eth-over-80216-05.txt]. It should be noted that only the 19 IP specific part of the packet CS is a mandatory requirement and support for 802.3 and 802.1Q parts of the packet 20 CS is optional. 21


Page - 65


7.2.2.1 Link Model 1 The MS and the IPv6 AR are connected at the IPv6 layer by a point-to-point link. The combination of the transport 2 connection over the air interface (R1) between the MS and the BS and, a GRE tunnel between the BS and the IPv6 3 AR ( i.e. R6) creates a p oint-to-point l ink. Each MS i s assigned a unique IPv6 prefix(es) by the AR. The AR i s a 4 function at the ASN-GW. A GRE tunnel, the granularity of which is per-service flow basis is established between 5 the BS and the AR. The figure below shows the link model: 6

ASN NodeB/BTS

CSN HA

MS CSN ASN-GW (AR) BS R1 R3

PHY PHY

MAC LNK IP GRE

IPv6

AR is the 1st hop Router for the MS

R6

IP-CS IP-CS MAC PHY

PHY LNK IP

GRE IPv6 LNK PHY

IPv6 IPv6

LNK PHY

Internet

IPv6 Link

ASN-GW (AR) MS

7

Figure 7-7 - IPv6 link model 8

9

7.2.2.2 IPv6 Address Management 10 The PoA address in the context of Mobile IPv6 can be either the CoA or the HoA. The CoA is the address whose 11 scope is at the IPv6 AR in the ASN. The HoA is the address whose scope is at the MS’ home agent. Only a M IP6 12 MS has a HoA and a CoA. The MIP6 MS can use either the HoA or the CoA for its IP sessions. All IPv6 MS’ that 13 attach t o t he ne twork a nd e stablish a n I Pv6 c onnection have a p refix a ssigned b y t he I Pv6 AR. T he a ddress 14 associated with the AR can be used by an MS for IP sessions. A MIP6 MS also uses this address to register it with 15 the HA in the binding update message. The PoA address for an MS that does not use MIP6 is the address obtained 16 via DHCPv6 or the address generated by stateless address auto-configuration based on the prefix advertised to the 17 MS by the IPv6 AR. 18

Each ASN SHALL advertise IPv6 prefixes that belongs to directly connected CSN(s) and which are topologically 19 anchored at t hat CSN. ASN S HALL NOT ad vertise an y o ther p refixes b esides t hose f rom directly co nnected 20 CSN(s). I n t his s cheme, ASN b ecomes t opologically a subnet o f a d irectly co nnected C SN(s). T ransport p aths 21 between a NAP and connected CSN(s) are established by means which are outside of scope of this specification. 22


Page - 66


In a r oaming s cenario, a h ome N SP i s n ot d irectly co nnected t o t he N AP. I nstead, a h ome N SP h as a r oaming 1 agreement with another NSP, called visited NSP, which has direct connection to the NAP’s network. In this case, 2 the home NSP SHALL NOT provide a NAP with a prefix to be advertised to the MS. The prefix advertised by the 3 ASN MUST be the prefix owned by the directly attached CSN with which the home NSP has a roaming agreement. 4

ASN may be preconfigured with different pools of CSN-owned prefixes at the time when the relationship between 5 the NAP and the NSP is set up, or the ASN may learn a p refix in a d ynamic manner when the MS attaches to the 6 network. 7

R3

R3

ASN

CSN

CSN

R5

V-NSP-1

NAP

H-NSP-3

CSNV-NSP-2

CSN

prefix y::/32

prefix x::/32MS1

(NSP-1)

MS2(NSP-2)

MS3(NSP-3)

adress x1::/64

adress y1::/64

adress y2::/64

8

Figure 7-8 - IPv6 address configuration 9

In figure above MS1 is subscriber of NSP-1, MS2 is a subscriber of NSP-2 and MS3 is subscriber of NSP-3. MS1 is 10 assigned a prefix from x::/32 range owned by NSP-1. MS2 is assigned a prefix from y::/32 range owned by the NSP-11 2. MS3 is roaming and its visited NSP is NSP-2, thus the MS3 is assigned a prefix owned by the NSP-2, i.e., from 12 y::/32 range. 13

When the ASN is preconfigured with the prefix pools, the ASN must associate prefix pools with the realm of the 14 NSP to which the prefixes belong. During the initial network attachment, the ASN will use the realm part of the NAI 15 to identify the prefix pool from which it shall select the prefix offered to the MS. 16

If t he I Pv6 p refix i s d ynamically as signed d uring MS a ttachment, the AAA s erver f rom the d irectly at tached 17 network will p rovide t he p refix i n t he AAA response message indicating success. In case o f roaming, the visited 18 AAA server SHALL provide ASN with a prefix. Dynamic assignment of IPv6 prefix by AAA server affects the 19 CMIP6 handovers. Before the ASN can initiate CMIP6 handover by sending a Router Advertisement message with 20 a n ew p refix, t he t arget ASN must acq uire a new p refix f orm t he AAA server b y means n ot specified b y t his 21 specification. The prefix selection process at the AAA server is out of the scope of this document, but the AAA 22 server must ensure that the assigned prefix is routable to the target ASN. 23

There ar e n o r estrictions r elated t o t he home ad dress o f t he MS : i n a r oaming cas e t he h ome ad dress co uld b e 24 anchored either in the home NSP or in the visited NSP. 25

IPv6 address assignment requirements and procedures are detailed in the following sections: 26

7.2.2.2.1 MS Functional Requirement 27 a) For f ixed/nomadic acces s, a M S M AY b e al located a P oA ad dress f or s imple IP co nnectivity b y ei ther 28

static, s tateless a ddress a uto-configuration ( SLAAC, [16] a nd [ 30]) m eans o r st ateful D HCPv6 [ 42] 29 assignment. 30


Page - 67


b) MS s hould support s tatic, dy namic, stateless or stateful [ 42] a ddress a ssignment for h ome a ddress 1 assignment. 2

c) MS should support stateful address auto-configuration [42] or stateless auto-configuration ([16] and [30]) 3 for CoA allocation. 4

d) MS SHALL use DHCPv6 [42] to determine system configuration information such as DNS servers, NTP 5 servers, etc. 6

e) The MS SHALL be assigned a / 128 prefix for a s ingle CoA assignment. Alternatively, the MS MAY be 7 assigned a /64 prefix, w hich it m ay u se t o configure o ne or more addresses o n its interface. If multiple 8 addresses are configured, the MS MAY use any o f t hese as the CoA for a Mo bile IPv6 Binding Update 9 (BU). 10

f) Allocation o f P oA SHALL NOT p reclude th e a llocation o f a dditional tunnel I P a ddresses t o acce ss 11 applications (i.e., VPN). 12

g) For billable IP services, the PoA SHALL be allocated only after successful user/device authorization. 13

h) PoA SHALL be bound to user/device for the duration of the session. 14

i) When PoA=CoA, it SHALL always be allocated by the serving network (visited or home). 15

j) MS M AY use Neighbor Discovery [ 15] t o a cquire I P c onfiguration i nformation s uch a s pr efix, r outer 16 address, etc. 17

7.2.2.2.1.1 Fixed Access /Stationary Networks Scenario 18 Fixed usage SHALL allow two types of PoA IP address allocations via s tatic/manual configuration, DHCPv6 and 19 stateless address auto-configuration (SLAAC): 20

• Static IP address: An MS may be provisioned with a static IPv6 address. In the case of an MS operating IPv6 21 over IPv6CS, the IPv6 AR is located in the ASN and the address assigned to the SS is based on the 22 prefix/subnet of the AR. In the case of IPv6 over Ethernet CS, the address pool comes from an AR that acts as 23 the 1st hop router for the SS. An example of such an AR would be the BRAS in a DSL type of deployment. 24

• Stateful address auto-configuration: Stateful address auto-configuration is based on DHCPv6 [42]. The 25 DHCPv6 server SHALL reside in the Visited CSN domain that allocates the PoA address. A DHCPv6 relay 26 MAY exist in the network path to the CSN. 27

• Stateless address auto-configuration (SLAAC): An SS at the completion of the establishment of the initial 28 service flow (ISF) sends a router solicitation to the all-routers multicast address. The AR in the ASN can also 29 send an unsolicited router advertisement to the SS on completion of the ISF establishment. The AR in the ASN 30 responds to the router solicitation with a router advertisement which contains the prefix(es) that can be used by 31 the SS to do SLAAC. The SS SHALL perform DAD on the address that it autoconfigures. 32

7.2.2.2.1.2 Nomadic Access Scenario 33 Nomadic access SHALL allow two types of PoA IP address associations. 34

• Stateful address auto-configuration : Stateful address auto-configuration is based on DHCPv6 [42]. The DHCP 35 server SHALL reside in the Visited CSN domain that allocates the PoA address. A DHCP relay SHALL exist 36 in the network path to the CSN. 37

• Stateless address auto-configuration : The SS/MS sends a router solicitation to the all-routers multicast address 38 at the completion of the establishment of the ISF. The AR in the ASN responds with a router advertisement 39 which includes the prefix(es) that can be used to auto-configure an address. The MS SHALL perform DAD on 40 the address that it auto-configures. The AR should also send an unsolicited router advertisement to the MS at 41 the completion of the establishment of the ISF. 42

7.2.2.2.1.3 Portable, Simple and Full-Mobility Access Scenario 43 Mobility (R3 mobility) in the case of IPv6 is enabled via Mobile IPv6. IPv6 in this release is an optional feature. 44 Mobile IPv6 is hence an optional feature as well. Mobile IPv6 in this release is as per RFC 3775. Mobility service 45


Page - 68


requires the MS having a home address (HoA) and at least one care-of-address (CoA). Both addresses are globally 1 routable. CoA is the address whose scope belongs to the AR in the ASN. The HoA is the address the scope of which 2 is at the MIP6 Home Agent. Address assignment is via stateful and SLAAC means. The HoA may also be statically 3 configured at the MS. The CoA address allocation occurs as follows: 4

• SLAAC: An Initial Service flow (ISF) is established on completion of .16e Registration by the MS. The MS 5 sends a Router solicitation to the AR. The AR in the ASN responds with a router advertisement (RA) which 6 includes the prefix(es) that enable the MS to autoconfigure an address. The AR should also send an unsolicited 7 RA on completion of the establishment of an ISF for an MS. 8

• Stateful address auto-configuration: The MS acquires an address from the ASN via DHCPv6. DHCPv6 is 9 initiated only after the establishment of the ISF. 10

The HoA for an MS is assigned as follows (RFC 3775 and related IETF standards): 11

• Stateless DHCP: During initial access authentication, the Home AAA determines the MS is authorized for 12 MIP6 service and sends the bootstrap parameters required by the MS in the AAA response message indicating 13 success to the visited AAA in the ASN. The ASN inserts the MIP6 bootstrap parameters which include the 14 address of the HA, the home link prefix or the HoA in the stateless DHCPv6 server in the ASN. On completion 15 of the establishment of the ISF, the MS sends a DHCPv6 query to the DHCP server in the ASN and receives the 16 MIP6 bootstrap parameters. If the MS receives the Home link prefix, the MS does SLAAC to configure the 17 home address. If the DHCP response includes the HoA then the MS uses the HoA in the binding update to the 18 HA. If the Home AAA does not provide either the home link prefix or the HoA, the MS can send a binding 19 update to the HA with the HoA set to the unspecified address. In such a case the HA will assign the MS a HoA 20 in the binding Ack. 21

7.2.2.2.2 Functional Decomposition 22 As per WIMAX reference model, functional decomposition for MS PoA IP address management feature SHALL be 23 done across the following reference points: 24

a) R1 25

b) R3 26

c) R5 if applicable 27

SS/MS

AddressAllocation

Server

ASN CSN

CSN

R1 R3 R5

AAModule

AR

AAAClient

DHCPRelay

DHCPClient

Auth Server/EAP server

Profiles,Credentials,

Policies

28

Figure 7-9 - Stateful MS IPv6 Address Management 29

There are two methods for address allocation: 30

• The PoA address MAY be allocated by the Address Allocation Server in the Serving Network [42]. This could 31 be in the home network if the device is not roaming or in the visited network if the device is roaming (as per 32 roaming agreement with the Home NSP). 33

• The PoA MAY be derived using SLAAC. The CoA prefix belongs to the address range assigned to and 34 managed by the V-NSP. 35


Page - 69


The link-local address is always auto-configured by the MS as soon as the IPv6 radio bearer is established. Link-1 local address is formed by using the MS MAC address and the well-known l ink-local prefix, as described in [15] 2 and [16]. The MS SHALL perform duplicate address detection on its link-local address [16]. If later the MS auto-3 configures a CoA by combining the same interface identifier it used for link-local address with an advertised prefix, 4 the MS doesn’t need to perform duplicate address detection process for such address. The MS will use its link local 5 address as source address in any IPv6 datagrams that it sends before it has acquired a global address. 6

7.2.2.3 IP Address Renewal 7 An MS that is assigned an address via DHCPv6 should renew the address when the lease lifetime nears expiry. The 8 MS triggers DHCP renewal and the process is as per [42]. 9

If an MS has an address that i s acquired via SLAAC, the MS needs to renew the address b y sending a neighbor 10 solicitation to the AR. 11

7.2.2.4 DNS discovery 12 The MS can discover the address of the DNS via either one of the following methods: 13

• DHCPv6 14

• Well known DNS address 15

• Address of the DNS server in the router advertisement 16

7.2.2.5 Addressing principles for PMIP6 17 WiMAX® networks SHOULD support both stateless and stateful IPv6 address autoconfiguration methods within the 18 PMIP6 scope. 19

Depending on the configuration and preferences, MS can try to configure an IPv4 address by DHCPv4, one or more 20 IPv6 addresses by DHCPv6 or stateless address autoconfiguration. If permitted, the address / prefix will be delivered 21 by t he d esignated network e ntity i n t he co rrect r esponding form. T he ex changed s ignaling r elated t o ad dress 22 configuration may a lso serve for mobility service type indication purpose. I f for any reason the network needs to 23 enforce a s pecific configuration method i t must set t he particular address configuration flags in the RA messages 24 (ManagedFlag and OtherConfigFlag) to do so. 25

The HNP for the PMIP6 MN-HoA may be allocated from two sources, the LMA or the AAA server. 26

• Prefix/HoA can be bootstrapped from the dedicated AAA server during the network authentication process. 27

• PMIP6 LMA assigns the unique/64 IPv6 prefix in response to the PBU message from the AR/MAG (ASN) 28 with H ome P refix opt ion s et t o ALL_ZERO, when H NP h as not be en obt ained through n etwork 29 authentication. 30

31

MS is able to configure its HoA address in two different ways, depending on the address configuration model the 32 access network provides, or the MS policy store specifies. The MS either autoconfigures an address from this HNP 33 or uses the stateful address allocation method to configure an IPv6 address. For IPv4 host IPv4-MN-HoA allocation 34 only takes place through the DHCPv4 procedure. 35

• The MS behavior is per [NWGR1.0] in support of the IPv6 stateless address autoconfiguration. 36

• HoA/128 address is assigned by the DHCPv6 server in case of stateful address configuration for the MS 37 (when M anagedFlag a nd O therConfigFlag b its s et i n t he r esponding RA). I n t his case t he a ddress 38 configuration process takes place over the DHCP Relay/Proxy function in the ASN. 39

Either DHCP Proxy or DHCP Relay entity in the ASN is needed to support stateful IPv6 address autoconfiguration 40 for the MS. It is assumed that the DHCP Proxy or Relay is always co-located with the AR/MAG functional entity in 41 the ASN. 42


Page - 70


7.3 AAA Framework 1

The WiMAX® AAA framework is based on IETF specifications, in particular on [23], [24], [50] and [89]. The term 2 AAA is used to refer to the AAA protocols, RADIUS or Diameter. 3

The AAA framework provides the following services to WiMAX: 4

• Authentication Services. These include device, user, or combined device and user authentication. 5

• Authorization Services. These include the delivery of information to configure the session for access, 6 mobility, QoS and other applications. 7

• Accounting Services. These include the delivery of information for the purpose of billing (both prepaid 8 and post paid billing) and information that can be used to audit session activity by both the home NSP and 9 visited NSP. Accounting is described in section 7.5. 10

7.3.1 Functional Requirements 11 The following functional requirements are considered: 12

a) The A AA framework SHALL s upport g lobal r oaming across W iMAX ope rator n etworks, i ncluding 13 support for credential reuse and consistent use of authorization and accounting. 14

b) The AAA framework SHALL support roaming between home and visited NSPs. 15

c) The AAA framework SHALL be based on us e of RADIUS or Diameter in the WiMAX ASN and CSN. 16 Where applicable, an Interworking gateway SHALL translate between either of these Diameter or RADIUS 17 protocols. As well an interworking function maybe required for translating between one of these protocols 18 and a legacy domain-specific protocol. 19

d) The AAA f ramework S HALL b e c ompatible with t he AAA 3 -party scheme - with a n M S a s a 20 “Supplicant,” “Authenticator” in ASN, and an AAA backend as an “Authentication Server.” 21

e) The AAA framework SHALL be compatible with AAA authorization requirements as per [27]. 22

f) The AAA framework SHALL accommodate both Mobile IPv4 and Mobile IPv6 Security Association (SA) 23 management. 24

g) The AAA framework SHALL acco mmodate al l the scenarios o f operation from f ixed t o full mobility as 25 defined in WiMAX Forum Stage 1 document [79]. 26

h) The A AA framework S HALL provide s upport f or de ploying M S a uthorization, user a nd mutual 27 authentication between MS and the NSP based on PKMv2. 28

i) In o rder t o e nsure i nter-operability, the AAA framework S HALL s upport E AP-based au thentication 29 mechanisms that MAY include but are not limited to the following: passwords or shared secrets, Subscriber 30 Identity Module (SIM), Universal Subscriber Identity Module (USIM), Universal Integrated Circuit Card 31 (UICC), Removable User Identity Module (RUIM), and X.509 digital certificates. 32

j) AAA framework SHALL provide appropriate support for policy provisioning at ASN or CSN, for instance 33 by carrying policy related information from AAA server to ASN or CSN. 34

k) The AAA framework SHALL support dynamic change of authorization updates e.g., as described in [48] 35 and [50]. This information includes but not limited to the identity of the visited network, and the location of 36 the MS as known by the ASN. 37

l) The AAA framework S HALL b e cap able o f p roviding t he V isited CSN o r ASN with a “handle” t hat 38 represents the user without revealing the user’s identity. This handle MAY be used by entities external to 39 the Home CSN for billing and for enforcement of service level agreements. 40

m) In o rder to s upport s ome a pplications such a s d ynamic authentication, the AAA f ramework M AY b e 41 required to maintain session s tate. In the case o f RADIUS [23] (a s tateless p rotocol) the maintenance o f 42 session state is an implementation detail. 43


Page - 71


n) The AAA framework shall allow the classification of user profiles as fixed, nomadic or mobile to support 1 commercial t iered s ervices b ased o n mobility au thorization l evels o n o ne hand an d to s upport N AP 2 regulatory restrictions on the other. 3

o) The AAA framework may allow multiple mobility classifications per user profile based on the NAP ID or 4 the NSP ID originating the network access authorization request. 5

p) The AAA framework shall allow the configuration and association of a Network Entry Zone to each fixed 6 or nomadic subscriber mobility profile 7

q) The AAA shall be able to extract the MS CRN (Certification Registration Number) from the NAI when this 8 decoration is appended to the NAI. 9

r) The AAA shall be able to obtain the MS certified feature lists from a Certification DB using the MS IPID 10 (Integral Platform ID) as the input or from internal policy DB in the case the MS has a record in the AAA. 11

s) The AAA shall check for MS IPID changes by comparing the transmitted IPID with the stored IPID for the 12 MS and may update the MS allowed features based on the update. 13

t) The AAA may verify the CRN part of the MS transmitted IPID by comparing the device model from the 14 device certificate information with the device model stored in the certification DB. 15

u) The AAA shall generate the allowed MS-Certified-Feature-List. This can be based on the certified features 16 combined with the E2E capabilities and operator policy of the connected NW. 17

v) Based on allowed MS-Certified-Feature-List and operator policy: 18

a. The AAA notifies the NAS with the allowed MS-Certified-Feature-List. Or, 19

b. The AAA may check for the availability of SW update for the MS and may hotline it for the 20 purpose of software update. Or, 21

c. The AAA may reject the MS with a reason of “Certification Version incompatibility” 22

7.3.2 Reference Point Security 23 In o rder t o en sure en d-to-end security o f the WiMAX Forum® Network Architecture, s ecurity of eac h r eference 24 point must be considered. Privacy, authentication, integrity and replay protection must be ensured either at the lower 25 layers (phy, mac, or network layer) or at the higher layers. Security at the lower layers comes in the form of a secure 26 channel that can be utilized by any one of the signaling protocols and data traffic running above it. 27

It should be no ted that the lower l ayer security a nd the hi gher l ayer security are co mplementary. Absence o f one 28 should be compensated by the presence of the other. At times both may be present. Lower layer security between 29 two end points can be a substitute for the higher layers that terminate on the same end points. If the end points are 30 different, the substitution may not apply. For example, a secure channel between the BS and the ASN GW alleviates 31 the need to secure any R6 signaling, but pass-through R2 signaling cannot rely on this security. 32

Deployments must be a ware o f t he necessity a nd av ailability o f l ayered-security for each r eference p oint. T his 33 section provides a guideline to deployments. 34

R1 - The IEEE Std 802.16 primary management connection over R1 is authenticated, integrity and replay protected 35 at the IEEE 802.16 MAC layer upon successful Device Authentication. All the subsequent R1 messaging over these 36 connections can rely on this lower-layer cryptographic security. On the other hand, transport connections may not be 37 crypto-protected a t a ll. F or t hat, a ny signaling pr otocol a nd da ta t raffic that r un a bove t hese c onnections s hall 38 provide t heir o wn s ecurity when ne cessary. ( Note: Although e nabling s ecurity o n t he t ransport c onnections is 39 optional, it is recommended that deployments take advantage of this feature). 40

R2 - This reference point may not have an end-to-end secure channel. It shall be assumed that the lower-layers are 41 insecure and the signaling protocols and data traffic shall provide their own security when necessary. 42

R3 - This reference point may not have an end-to-end secure channel. It shall be assumed that the lower-layers are 43 insecure a nd t he s ignaling p rotocols an d d ata t raffic s hall p rovide t heir o wn s ecurity when needed. E xamples: 44 Mobile IPv4 using authentication extensions, RADIUS using authentication attribute, etc. 45


Page - 72


R4 - This r eference p oint has an en d-to-end s ecure c hannel, i ncluding p rivacy. T he c hannel s ecurity may b e 1 implemented using physical security, IPsec or SSL VPNs, etc. The VPN end points may be collocated with the R4 2 end points, or be on-path between the two to ensure end-to-end security. 3

R5 - This reference point may not have an end-to-end secure channel. It shall be assumed that the lower-layers are 4 insecure a nd t he s ignaling p rotocols an d d ata t raffic s hall p rovide t heir o wn s ecurity w hen ne eded. Examples: 5 RADIUS authentication attribute, etc. 6



7.3.3 Functional Decomposition 13 RFC2904 [ 25], pr esents t hree models f or de ploying AAA framework n amely, Agent s equence/model, P ull 14 sequence/model and Push sequence/model. The models mainly differ in two aspects namely, a) how the supplicant 15 and authentication server communicate and b) how the control information (e.g., keys, policy details) are configured 16 into the bearer plane MSs. The [25] does not recommend one model over another. On the contrary it suggests that it 17 is appropriate to deploy a hybrid model. A r elated [ 26] pr ovides e xamples of various key applications deployed 18 using the models defined in [25]. As per examples in the [25], the pull model i s a preferred model for deploying 19 AAA framework a nd ot her models c an be mixed i n when r equired. P ull model i s r ecommended for AAA 20 deployments within WiMAX networks. For more details on these models and terms like supplicant, authentication 21 server please refer to [25]. 22

The NAP MAY deploy an AAA proxy between the Network Access Server NAS(s) in the ASN and the AAA in the 23 CSN in o rder t o provide s ecurity and enhance maintainability. This is p articularly the case where the ASN has 24 many NASs and the CSN is in another administrative domain. I n this case, the AAA proxy will make it easier to 25 configure the AAA infrastructure between the NAP and the visited CSN, reducing the number of shared secrets that 26 need to be configured and making it easier to configure the network for failover. The AAA proxy will also allow the 27 NAP to police the AAA attributes received from the visited CSN and add additional AAA attributes that MAY be 28 required by the NASs in the ASN. Note: This Proxy AAA is not shown in the subsequent figures in this section. 29

7.3.3.1 Non-Roaming Pull Model 30 Figure 7-10 shows the non-roaming pull model as per [25]. 31

User

Service Provider

Service Equipment

AAA Server

4

1

2 3

32

Figure 7-10 - Generic Non-roaming AAA Framework 33

The User (e.g., MS) sends a request to the Service Equipment (e.g., Network Access Server - NAS). 34

The Service Equipment forwards the request to the Service Provider’s AAA Server. 35


Page - 73


Service Provider’s AAA server evaluates the request and returns an appropriate response to the Service Equipment. 1

Service Equipment provisions the bearer plane and notifies the user that it is ready. 2

Figure 7-11 shows the non-roaming pull model mapped to the WiMAX non-roaming reference model. 3

NAS AAAServer

MS

CSNASN1

423

4

Figure 7-11 - Greenfield Non-roaming AAA Framework 5

For more details on W iMAX® reference model, please r efer to S ection 6. As shown i n Figure 7-11, the Service 6 Provider is split into ASN and CSN, while the Service Equipment in the ASN becomes a NAS. The CSN hosts the 7 AAA server whereas the ASN hosts one or more NASs. 8

Figure 7-12 shows t he c orresponding W IMAX non-roaming r eference model when t he C SN i s be longing t o a n 9 incumbent N SP whose a uthorization a nd a uthentication b ackend is not AAA protocol c ompliant. T he 10 incompatibility can be at the protocol level or at attributes level, etc. 11

MS NAS IWG

Incumbent CSNASNR1 R3

1

4

2

3

12

Figure 7-12 - Non AAA Compliant Incumbent Non-roaming AAA Framework 13

In t his s cenario, the CSN o f an incumbent NSP needs t o host an internetworking gateway ( IWG) t o map AAA 14 protocols and attributes to incumbent NSP specific protocols and attributes and vice-versa Since the IWG translates 15 the AAA pr otocol t he I ncumbent N on-roaming cas e i s f unctionally i dentical t o t he N on-roaming ca se p resented 16 earlier. 17

7.3.3.2 Roaming Pull Model 18 Figure 7-13 shows the roaming pull model as per [25]. 19

User Service Equipment

AAA Proxy/Server

Service Provider

AAA Server

User Home Organization2b

3a

3b2a

4

1

20

Figure 7-13 - Generic Roaming AAA Framework 21

Figure 7-14 shows the corresponding WiMAX roaming reference model. 22


Page - 74


MS NAS AAA Proxy/Server AAA Server14

ASN

3b2a 2b

3a

CSN in Visited NSP CSN in Home NSP

1

Figure 7-14 - Greenfield Roaming AAA Framework 2

In c ase of r oaming de ployments, opt ionally on e or more AAA pr oxy/server e ntities e xist be tween ASN a nd t he 3 home CSN. 4

Figure 7-15 shows the corresponding WiMAX roaming reference model when CSN is in an incumbent home NSP 5 whose authorization and authentication backend is not RADIUS/Diameter compliant. As in the non-roaming case, 6 the incumbent home NSP will host an IWG to map the AAA protocols and a ttributes t o incumbent NSP specific 7 protocols and attributes, and vice-versa. 8

MS NAS AAA Proxy/Server IWG41

ASN2a

3b

CSN in Visited NSP2b

3a

CSN in IncumbentHome NSP

9

Figure 7-15 - Non AAA Complaint Incumbent Roaming AAA Framework 10

7.3.3.3 Decomposition of AAA in the ASN 11 As was shown in the above diagrams, the ASN is composed of one or more NASs. A NAS is considered as the first 12 AAA client where AAA messages originate and authentication and authorization attributes are delivered to. It is also 13 one source of accounting information (the accounting client may also be located in the CSN/Home Agent). 14

The A uthentication a nd authorization at tributes ar e d elivered t o A AA “Applications” s uch as , t he Authenticator, 15 mobility applications (PMIP, FA), prepaid applications, QoS applications, which collectively are assumed to live in 16 the N AS. W ith r espect to t he i mplementation o f t he ASN, t hese ap plications M AY a ctually r eside i n d ifferent 17 physical elements in the ASN. T hat is, the NAS MAY be implemented on multiple physical functional entities in 18 the ASN. 19


Page - 75


7.3.4 RADIUS Reference Protocol Stack 1 The following figure describes the RADIUS Reference Protocol Stack. 2

RADIUS

UDP

IP

LinkLayer

PHY

RADIUS

UDP

IP

LinkLayer

PHY

RADIUS

UDP

IP

LinkLayer

PHY

RADIUS

UDP

IP

LinkLayer

PHY

RADIUS

UDP

IP

LinkLayer

PHY

RADIUS

UDP

IP

LinkLayer

PHY

AAAclient

RADIUSVisited

RADIUSBroker

(optional)

RADIUSHome

3

Figure 7-16 - RADIUS Reference Protocol Stack 4

As shown RADIUS is based on UDP protocol and as such RADIUS protocol uses a handshake (request reply) to 5 provide its own robustness. Retry and Failover mechanisms are left as an implementation detail. 6

Therefore, the WiMAX® network should define a retransmission strategy that reacts to network congestion and thus 7 does not contribute to the congestive collapse of the network. 8

7.3.5 Diameter Reference Protocol Stack 9 The following figure describes the Diameter Reference Protocol Stack. 10

Diameter

TCP/SCTP

IP

LinkLayer

PHY

Diameter

TCP/SCTP

IP

LinkLayer

PHY

Diameter

TCP/SCTP

IP

LinkLayer

PHY

Diameter

TCP/SCTP

IP

LinkLayer

PHY

Diameter

TCP/SCTP

IP

LinkLayer

PHY

Diameter

TCP/SCTP

IP

LinkLayer

PHY

AAAclient

DiameterVisited

DiameterBroker

(optional)

DiameterHome

11

Figure 7-17 - Diameter Reference Protocol Stack 12


Page - 76


As s hown D iameter i s ba sed on T CP/SCTP protocol a nd a s s uch D iameter pr otocol r elies on t hese t ransport 1 protocols’ reliable delivery. Per RFC 3588 [50], AAA client SHALL implement either TCP or SCTP, and visited 2 and home AAA servers SHALL implement both TCP and SCTP. 3

7.3.6 RADIUS-Diameter Coexistence 4 WiMAX® networks SHALL support at least one of the RADIUS or Diameter protocols. Whether an ASN, VCSN, 5 or H CSN s upport on e or b oth of t hese pr otocols i s i ts o perator’s de cision. I f t wo n etworks a re i n a r oaming 6 agreement but not willing to support the same AAA protocol, then they need to rely on RADIUS-Diameter protocol 7 translation. 8

7.3.7 Routing of AAA messages 9 As specified above, AAA protocols a re hop by hop protocols. D uring operations the AAA messages SHALL be 10 routed between the NAS and the home AAA server. The routing of the messages typically depends on the NAI but 11 MAY al so d epend o n o ther attributes i n t he AAA m essages. E ach o perational s cenario S HOULD d iscuss how 12 messages are routed. 13

7.3.8 AAA Security 14 The IETF AAA protocols are hop-by-hop secure. That is, the AAA nodes are assumed to be trustworthy. 15

The A AA pr otocols p rovide p rotection a gainst multiple t ypes o f e xternal t hreats e .g., man-in-middle a ttacks. I n 16 RADIUS the protocol provides a mechanism to provide integrity protection, privacy, and protection against replay 17 attacks. This mechanism is protected by a key that is shared between the RADIUS hops. 18

RADIUS may a lso be pr otected u sing I Psec. H owever, I Psec i s n ot pa rt of t he R ADIUS pr otocol. Diameter i s 19 protected by using either IPsec or TLS. Neither of these two security protocols are part of the Diameter protocol 20

This specification s trongly r ecommends protecting the reference points an d interfaces between all interconnected 21 AAA client, proxy and server entities; however, the decision on a specific protection method remains a deployment-22 specific decision. 23

AAA i nfrastructure uses a number o f d ata s tores. T hese i nclude t he u ser’s i dentity store, p olicy stores, an d an 24 accounting store that contains accounting information collected for a p eriod of time. These stores must be secured 25 and maintained. T he p rocedures f or p rovisioning, maintaining, a nd s ecuring t hese s tores a re no t p art o f t his 26 specification. 27

7.3.9 Authentication and Authorization Protocols 28 IEEE Std 802.16-2004 October 2004, and IEEE Std 802.16e-2005 March 2006 specify PKMv1 and PKMv2 with 29 Extensible Authentication Protocol (EAP) for user authentication and MS authorization. PKMv1 provides support 30 for o nly D evice Authentication whereas P KMv2 p rovides a f lexible s olution t hat s upports d evice a nd us er 31 authentication between MS and home CSN. 32

In t he ar chitecture s pecified within t his doc ument, a uthentication a nd a uthorization must be ba sed on E AP 33 (Extensible Authentication Protocol, compliant to [52]). In order to work with EAP, IEEE Std 802.16e PKMv2 must 34 be us ed b etween M S a nd ASN. Within the ASN, Intra ASN security d escribes a dditional steps to transfer E AP 35 messages and keys within the ASN entities. Between AAA server and authenticator in ASN, EAP runs over either 36 RADIUS [49] or Diameter [89]. 37

The AAA framework used for network access authentication and authorization can transparently support different 38 EAP methods. However, all EAP methods: 39

• must fulfill the requirements to EAP methods specified in 802.16e for PKMv2 (e.g., those related to [81]), 40

• must generate MSK and EMSK as required by [52], and 41

• have to be chosen to support the provisioned credential types (details of allowed credential type mappings 42 to specific authentication modes (user/device/user and device) and the location of the EAP server 43 (ASN/Visited CSN/home CSN) are provided as part of the WiMAX Stage-3 specifications. 44

The d ifferent c redential t ypes supported in WiMAX network access authentication and authorization are l isted in 45 Table 7-1. 46


Page - 77


Table 7-1 - Credential Types for User and Device Authentication 1

Credential Instances Description

SUBC 0-1 The Subscriber Root Key (SUBC) is used to authenticate the subscriber. The size of the SUBC is EAP-method specific. The SUBC is also known by the HAAA. This is a long term key.

If device-Only authentication is performed, then the SUBC need not be provisioned.

The SUBC must be stored securely and is never transported from the user or the HAAA.

Device-Cert 1 Private/Public Certificate based keys used to authenticate the device. The certificate conforms to X.509. This is a long term credential.

The Private/Public Certificate based keys are configured at the device. The private key must be stored securely and is never transported outside the device.

Device-PSK 0-n Preshared Key (PSK) used to authenticate the device. The PSK is also provisioned at the realm responsible for authenticating the device. There may be a PSK provisioned for each realm or PSK may be shared by more than one realm. The latter case should be avoided since sharing of the PSK increase security risk. The PSK is indexed by a NAI used during the EAP authentication. This PSK must be stored securely.

The provisioning of such credentials is not in scope of this document. 2

7.3.9.1 User Authentication 3 PKMv2 must be used to perform over-the-air user authentication. PKMv2 transfers EAP over the IEEE 802.16 air 4 interface between MS and BS in ASN. Depending on the Authenticator location in the ASN, a BS may forward EAP 5 messages over Authentication Relay protocol (e.g., over R6 reference point) to Authenticator. The AAA client on 6 the Authenticator encapsulates the EAP in AAA protocol packets and forwards them via one or more AAA proxies 7 to t he AAA Server in t he CSN of the home N SP, which holds t he subscription with the S upplicant. In roaming 8 scenarios, on e or more A AA br okers with AAA pr oxies may e xist b etween A uthenticator a nd A AA Server. A ll 9 AAA sessions always exist between the Authenticator and AAA server with optional AAA brokers just providing 10 conduit for NAI realm based routing. 11

Figure 7-15 illustrates the layering of user/Device Authentication protocols. 12

EAP methods such as EAP-TLS, EAP-AKA, EAP-TTLS

EAP

AAA ProtocolAuth. Relay ProtocolPKMv2

802.16 Auth. Relay Encapsulating Protocol UDP, TCP, SCTP/IP

Supplicant

MS

AuthenticationRelay

BS(ASN)

Authenticator

NAS(ASN)

AAAProxy(s)

AuthenticationServer

AAAServer

(Home CSN)

13

Figure 7-18 - PKMv2 User Authentication Protocols 14


Page - 78


7.3.9.2 Device Authentication 1 EAP must b e used f or Device Authentication. The RSA-based Device A uthentication modes and the n o 2 authorization mode specified in IEEE Std 802.16e are not supported. Only EAP-based authentication is supported. 3

EAP methods used for Device Authentication must generate the MSK and EMSK key. 4

7.3.9.2.1 NAI (Network Access Identifier) 5 The network access identifier (NAI) used in WiMAX® shall conform to [60]. I t is used as identifier within EAP-6 based user and device network access authentication. 7

In EAP there are two instances where the identity is to be specified. This is when the mobile responds to the EAP-8 Request Identity message (outer-identity), and the identity specified in the EAP method itself (inner-identity). The 9 outer-identity, as recommended by [81] and section 5.1 of [2], should be used primarily to route the packet and act 10 as a h int helping the EAP Authentication Server select the appropriate EAP method. The outer-identity is used to 11 populate the User-Name attribute/AVP of the AAA request messages. 12

The inner-identity is used to identify the user, or authenticated credentials. EAP methods that provide identity hiding 13 will transmit the inner-identity within an encrypted tunnel created by the EAP method. 14

In order to support identity hiding it shall be possible to carry the real identity of the MS in the inner-identity only. 15 For the outer-identity, in this case a pseudonym is used that can be resolved to the real user identity only by the MS 16 itself and the home CSN. 17

Device cr edentials can b e ei ther a D evice-Cert o r a D evice-PSK. T he E AP d evice i dentifier s hould b e a M AC 18 address or a n N AI i n t he form of M AC_address@NSP_domain, de pending on where t he D evice Authentication 19 terminates. 20

The outer NAI shall be decorated with MS IPID for the AAA to be able to identify the MS certified features. 21

7.3.9.2.2 Device Authentication Policy 22 It is assumed that MS and home CSN know the Device Authentication policy applicable for the home CSN, with 23 regard t o when the D evice Authentication n eeds t o b e performed. M S should l earn t he H ome C SN Device 24 Authentication p olicy a s p art o f th e M S p rovisioning p rocess. T he p olicy may d ictate n ot p erforming D evice 25 Authentication a t a ll, performing Device Authentication only a fter power-on, or something e lse. The pol icy is an 26 operator decision. A typical policy can be to perform both device and user authentication at each power on on ly. 27 Until the next t ime the MS powers off, user-only re-authentication may be sufficient to authorize IP access of the 28 MS. 29

Upon acces s t o t he serving system, t he M S must inform t he system o f i ts cap ability t o p erform t he D evice 30 Authentication. B ased on t he l ocal p olicy o f t he V isited A SN, t he MS may b e r equested to p erform th e D evice 31 Authentication if it is capable of doing so. Alternatively, based on the local policy, the Visited CSN may grant the 32 access bypassing Device Authentication, or refuse the service to the roaming MS. 33

The serving ASN does not have to know the Device Authentication policy of the Home CSN. 34

7.3.9.2.3 Executing User and Device Authentication 35 If b oth u ser an d d evice au thentication n eed t o b e p erformed, t here ar e t wo ways t o ach ieve t his: U sing E AP 36 tunneling, or combined authentication. 37

A t unneling E AP method ( e.g., EA P-TTLSv0) c an be used f or pe rforming t wo E AP a uthentication ov er what 38 appears like a single EAP session to both the PKMv2 and AAA protocols. The outer EAP method can be used for 39 device authentication and the inner EAP method can be used for user authentication. Both entities are authenticated 40 by the HCSN. 41

The other alternative is to use combined authentication. When both the user and Device Authentication are based on 42 PSK and terminate in the home CSN, the two will be performed jointly as one s ingle EAP authentication. In this 43 case, a combined identity is generated. One PSK-based EAP authentication must be performed using the computed 44 credential. A successful authentication between the MS and home CSN implicitly authenticates both the device and 45 the user. This o ptional optimization a ims at r educing the authentication s etup la tency. The MS is assumed to b e 46


Page - 79


informed of t he a vailability of this CSN feature e ither du ring t he pr ovisioning pr ocess, or t hroughout t he 1 negotiations phase. 2

In some deployments only Device Authentication is required. Device Authentication must terminate in the home 3 CSN in this case. 4

7.3.10 Authentication and Authorization Procedures 5

7.3.10.1 PKMv2 Procedure During Initial Network Entry 6 Figure 7-18 illustrates PKMv2 procedure during initial network entry of the MS. 7

SupplicantMS

BSASN

MS context initialization

Authenticator(NAS)ASN

AAA Proxy(s) AAA ServerHome CSN

EAP over AAA

80216e link up and SBC exchange

EAP Request/Identity

EAP Response/Identity

EAP Method (EAP-TTLSv0, EAP-AKA or EAP-TLS etc)

Master Session Key (MSK) Established in MS and AAA Server

MSK transferred to AuthenticatorPairwise Master Key (PMK)Generated in MS and Authenticator

Authorization Key (AK)Generated in MS and Authenticator

AK transferred to BS

SA-TEK RequestSA-TEK Challenge

SA-TEK Response

Key RequestKey Reply

Service Flow Creation (i.e. DSx exchange)

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(9)

802.16e REG(8) Registration

Path establishment

8

Figure 7-19 - PKMv2 Procedures 9

Steps for flow setup using PKMv2: 10

(1) Initiation of network entry according to IEEE Std 802.16e: 11

a) Upon successful completion of ranging, the MS SHALL send the SBC_Req message. 12


Page - 80


b) The ASN SHALL respond to the MS by sending the SBC_Rsp. During this SBC negotiation, the MS and 1 ASN SHALL negotiate the PKM version, PKMv2 security capabilities and authorization policy including 2 requirements and support for Device Authentication. 3

As a result of the successful establishment of an 802.16 air link between the BS and the MS, a link activation is sent 4 (e.g., over R6) to the Authenticator. This causes the Authenticator to begin the EAP sequence. 5

(2) EAP Exchange 6

The a uthenticator s ends a n E AP-Identity r equest t o t he s upplicant i .e. MS . D epending on t he Authenticator 7 location (i.e., BS or ASN-GW), the message may be transferred over the Authentication Relay protocol (across 8 the R6 r eference i nterface), is next en capsulated i nto a MAC management P DU a t the B S, a nd i s t hen 9 transmitted in an EAP-Transfer message [PKM-REQ(PKMv2 EAP-Transfer)]. 10

The supplicant receives the P KMv2 EAP-Transfer message, passes its p ayload to the local EAP method for 11 processing, a nd t hen when r esponse i s r eceived, t ransmits it in a P KMV2 E AP-Transfer message [ PKM-12 REQ(PKMv2 EAP-Transfer)]. From now o n the authenticator forwards al l the responses f rom the MS to the 13 AAA proxy, which then routes the packets based on the associated NAI realm. 14

(3) Shared Master Session Key (MSK) and Extended Master Session Key (EMSK) establishment 15

As part of successful EAP exchange in step 2), a Master Session Key (MSK) and an Extended Master Session 16 key (EMSK) are established at the MS and the Home AAA Server. The Home AAA Server then transfers the 17 generated MS K t o t he Authenticator ( NAS) i n t he ASN. T he MS K i s sent in t he AAA r esponse message 18 indicating success in a s ecure manner from the AAA Server to the ASN. The EMSK is retained at the Home 19 AAA Server. F rom t he M SK, b oth t he MS an d t he Authenticator g enerate a P MK as p er I EEE 8 02.16e 20 specifications. From the EMSK, the MS and the Home AAA Server generate the mobility keys. 21

The a uthentication p art o f t he a uthorization f low ( and t he i nvolvement o f t he generic E AP l ayer) i s no w 22 complete. 23

(4) Authentication Key (AK) generation 24

The Authenticator and the MS generate the AK from the PMK based on the algorithm specified in the IEEE 25 802.16e specification. 26

(5) AK Transfer 27

The Key Distributor entity in the Authenticator delivers the AK and its context to the Key Receiver entity in the 28 Serving BS. The Key Receiver caches the AK and relevant security context related to the MS and is responsible 29 of generating subsequent subordinate IEEE 802.16e- specified keys from the AK and its context. 30

(6) AK Liveliness establishment and SA transfer 31

To mutually prove possession of valid Security Association based on AK, the MS and the BS perform PKMv2 32 three-way handshake procedure. 33

The BS transmits the PKMv2 SA_TEK_Challenge message as a first step in the PKMv2 three-way handshake at 34 initial network e ntry a nd a t r eauthentication. I t identifies a n AK to be used for the Security Association, and 35 includes a unique challenge, i.e., BS Random, that can either be a random number or a counter. 36

The MS responds with the PKMv2 SA_TEK_Req message after receipt and successful CMAC verification of a 37 PKMv2 SA_TEK_Challenge from the BS. The PKMv2 SA_TEK_Req message contains the number, called MS-38 Random, which can also be either a random number or a counter. 39

The PKMv2 SA_TEK_Req proves liveliness of the Security Association in the MS a nd its p ossession o f t he 40 valid AK. Since this message is being generated during initial network entry, it constitutes a request for SA-41 Descriptors identifying the primary and static SAs, and GSAs the requesting SS is authorized to access, and 42 their particular properties (e.g., type, cryptographic suite). 43

The B S t ransmits the PKMv2 SA_TEK_Rsp message a s a t hird step in t he P KMv2 t hree-way handshake. I t 44 constitutes a lis t of SA-Descriptors identifying the primary and static SAs, the requesting SS is authorized to 45 access and their particular properties (e.g., type, cryptographic suite). 46


Page - 81


After the successful completion of PKMv2 three-way handshake, the MS and the BS shall start using the newly 1 acquired AK for MAC management messages protection (by CMAC) as per IEEE 802.16e specification. 2

(7) Traffic Encryption Key (TEK) generation and transfer 3

For each SA, the MS requests two TEKs from the BS. The TEKs are randomly created by the BS, encrypted 4 using the KEK as the symmetric secret key, and are transferred to the MS. This step is repeated for each SA. 5

(8) IEEE 802.16e Network Registration 6

After the successful PKMv2 three-way handshake completion (the MS receives PKMv2 SA_TEK_Rsp message 7 from the B S), t he MS S HALL send R EG R equest message t o the B S pr oviding ASN with t he s upported 8 registration parameters. The BS SHALL respond with REG Response message. During this REG exchange, the 9 MS an d ASN negotiate n etwork r egistration p arameters. T he B S m ay n egotiate t hese p arameters with t he 10 Authenticator entity in ASN GW (over R6). The completion of REG process is made known to Authenticator/ 11 ASN GW (over R6) and it triggers Service Flow and Data Path establishment process. 12

(9) Service Flow Creation 13

The Anchor SFA entity collocated with the Authenticator starts Service Flow and the corresponding Data Path 14 establishment process toward the BS. 15

The BS uses DSA-REQ/RSP/ACK MAC management messages to create a new service flow and map an SA to 16 it thereby associating the corresponding TEKs with it. 17

7.3.10.2 PKMv2 Procedure During Hand-off 18 The PKMv2 procedure during handoff SHALL be optimized according to the following guidelines: 19

a) When a mobile moves within the same mobility domain, the AK i s validated by s igning and verifying a 20 frame via the CMAC using the AK which is newly generated from the same PMK as long as the PMK 21 remains valid. 22

b) Validating the AK is usually combined with the procedure of ranging which include 802.16e RNG-REQ 23 and RNG-RSP with CMAC tuple. 24

c) Sharing T EK within a same mobility do main is pos sible when H andover pr ocedure b etween t wo b ase 25 stations can t ransfer T EK co ntext i nformation. I f t he T EK i s s hared a mong B Ss, t he s et o f B Ss ar e 26 considered as same security entities within a same trusted domain. 27

7.3.11 Certification Version Signaling (CVS) 28

7.3.11.1 Certification Version Signaling Procedure During Initial Network Entry 29 Figure 7-20 illustrates CVS procedure during initial network entry of the MS. 30

31


Page - 82


SupplicantMS

BSASN

MS context initialization

Authenticator(NAS)ASN

AAA Proxy(s) AAA ServerHome CSN

Cert-ID and E2E Capabilities included in EAP over AAA

80216e link up and SBC exchange

EAP Request/Identity

Cert-ID included in EAP Response/Identity


DBCertification

MS certified features request

MS certified features response

MS Supported

Apply Operator Policy

Connected

Allowed Certified MS Feature ListAllowed Certified MS

Feature List

Connected

SW upgrade available

Y

N

Y

N

Apply Hotline rules


SW Upgrade

Disconnected Disconnected

Notify Rejection and code

NW Rejection

Disconnected Disconnected

(2)

(1)

(3)

(4)

(5)

1

Figure 7-20 - CVS Procedures 2

Steps for CVS flow: 3

(1) Initiation of NW entry per IEEE Std 802.16e, the authenticator sends EAP_REQ_ID to initiate authentication. 4

(2) The MS replies with EAP response identity appending the IPID to the EAP identity. The AAA, based on t he 5 received MS IPID, obtains the supported features for this device from the certification DB. Then it applies the 6 E2E network capabilities and operator Policy and decides if the network can support this MS. 7

(3) If MS that can be supported by t he network – The AAA server notifies the NAS of the Allowed Certified MS 8 Feature List to enforce and contain the activated features for the MS once initial network entry is successfully 9 completed. 10


Page - 83


(4) For MS that cannot be supported – The AAA checks if a SW upgrade, that will make the MS supported by the 1 NW, is available and if so, the AAA may apply hotlining on the NAS and continue with normal network entry 2 for the purpose on SW upgrade. 3 Once the MS is connected, it is may be hotlined for SW upgrade and other treatment and once the upgrade is 4 completed, the MS is disconnected from the NW and may re-connect using the updated SW. 5

(5) For MS that cannot be supported or upgraded – the network rejects the MS and notifies the NAS about the 6 rejection and rejection reason. The network apply MS-Rejection p rocedure with the MS using CVS rejection 7 codes and criteria’s that ensure the MS will not return to the network frequently unless its SW was upgraded or 8 there is a chance that an upgrade became available to it on the network. 9

10

7.3.11.2 AAA decision flow with regards to MS in CVS mode 11 Figure 7-21 demonstrates the CVS decision making procedure in the AAA Server. 12

13

Start NE

AAA receives First Access

Request

AAA Extracts MS-Cert-ID

AAA Server looks uo Device Cert-ID DB fro

certified features

AAA Server compares E2E capabilities with

feature Requirement DB

AAA applies Operator Policy

Can MS be supported ?

Is SW upgrade available for MS

Optionally Hotline for SW upgrade

NW Exit

Continue Initial Network Entry Procedure

Reject MS (Rejection class of CVS)

N

Y

N

Y

14

Figure 7-21 - AAA Sever Decision CVS Procedures 15

7.3.11.3 Data bases to be used for CVS Process 16

7.3.11.3.1 Feature requirement Database (FRD) 17 This data base i s maintained at AAA and i t includes the specific feature required in the each network element i n 18 order to support an E2E feature. 19


Page - 84


The AAA uses it to find which features can be supported by a ll network elements and that based on its policy may 1 decide to enable the supported E2E feature for the MS. 2

The Implementation details of this database are outside the scope of WiMAX Forum® Network Architecture. The 3 following table demonstrates an example for content of such a database. 4

5

Feature MS BS ASN-GW CSN

1 (IPv4) Minimum MS Support Minimum BS support Min required GW support Min required CSN support

2 (IPv6) Minimum MS Support Minimum BS support Min required GW support Min required CSN support

3 (OTA) Same as Feature 1 N/A Min required GW support Min required CSN support

4 (LBS-C) Minimum MS Support N/A Min required GW support Min required CSN support

5 (LBS-U) Minimum MS Support N/A Min required GW support Min required CSN support

6 (MBS-DSx) Minimum MS Support Minimum BS support Min required GW support Min required CSN support

7 (MBS-App) Minimum MS Support Minimum BS support Min required GW support Min required CSN support

8 (USI) Same as Feature 1 N/A N/A Min required CSN support

9 (ROHC) Minimum MS Support Minimum BS support Min required GW support N/A

10 (PHS) Minimum MS Support Minimum BS support Min required GW support N/A

6

The minimum requirement for each network elements per feature shall be determined by the certification tests done 7 for their element with regards to each supported feature. 8

7.3.11.3.2 WiMAX® Products Certification DB (WPCD) 9 This data base is maintained by WiMAX Forum®, each operator AAA may have direct access to this DB and it may 10 also create a local copy for it. 11

The Database represents all the relevant certification information for a given device, based on the CRN (part of the 12 IPID) supplied by the device. 13

The Operator NW should use this DB to know what MS supports as an input to the FRD, it should be also used to 14 identify if a SW upgrade is available. 15

The details o f this database a re outside the scope o f WiMAX Forum® Network Architecture. T he following table 16 demonstrates an example for content of such a database. 17

CRN Manufacturer Hardware Model

Software version

Major release Certified Bands

Certified L1/LMAC Features

Certified E2E Features

21211243321221 Vendor X 3550 5.2.1 Release 1 1.A, 3.A MIMO A/B, HARQ-DL, HARQ-UL….

IPv4, OTA, EAP-TLS, EAP-TTLS

12121243421212 Vendor Y 23113 1.2.13.5 Release 1 3.A MIMO A, HARQ-DL, HARQ-UL…..

IPv4, IPv6, OTA, EAP-TLS, EAP-TTLS, LBS

78823233234234 Vendor X 3550 6.1.0 Release 1 1.A, 3.A MIMO A, HARQ-DL, HARQ-UL,…..

IPv4, IPv6, OTA, EAP-TLS, EAP-TTLS, EAP-AKA,


Page - 85


LBS-U, MBS-DSx, ROHC

28190232134543 Vendor Y 91213 2.3.14.2 Release 1 3.A, 4.A, 5.A

MIMO A/B, HARQ-DL, HARQ-UL…..

IPv4, IPv6, OTA, EAP-TLS, EAP-TTLS, LBS, MBS-App

1

7.3.11.3.3 WiMAX® Models Certification-IDs DB (WMCID) 2 This data base is maintained by WiMAX Forum®, each operator AAA may have direct access to this DB and it may 3 also create a local copy for it. 4

This database include all the valid certification IDs for a given Model and the relevant SW version. 5

The O perator m ay u se t his DB t o en sure t hat d evice ac tually cer tified f or t he CRN i t d eclared b ased o n t he 6 manufacturer and model extracted from the device certificate. 7

A device may use a CRN from Older SW version that it actually uses but not vice-versa. 8

The details o f this database a re outside the scope o f WiMAX Forum® Network Architecture. T he following table 9 demonstrates an example for content of such a database. 10

11

Manufacturer Hardware Model Hardware version {CRNSW version}

Vendor X 3550 1a {212112433212215.2.1}

{212112433256915.2.6}

{212112433298806.0.1}

{212112433367116.9.3}

Vendor Y 23113 {6744381433212781.00}

{6744381433212132.00}

{6744381433217232.5.2}

{6744381433219912.7.0}

Vendor Y 91213 {6744381433212871.0.6}

{6744381433212312.1.5}

{6744381433217772.5.0}

{6744381433219192.7.3}

12

7.3.12 Co-existence of Fixed/Nomadic Services with Mobility Services 13 Fixed, Nomadic and Mobility services may be simultaneously provided by a network. Such network configuration 14 provides coexistence of services support on a per user basis. Whether the fixed service or nomadic service or mobile 15 service is authorized by the network for a given user will depend on network capabilities negotiation between ASN, 16 V-CSN and H-CSN based on user’s subscription profile and operator policy. 17

7.3.12.1 Network Service Capability Negotiation and Selection Scheme 18 The scheme is to leverage the ASN access authentication process to negotiate necessary service capabilities among 19 ASN, V -CSN a nd H -CSN. New p arameters n amed ASN, V CSN “Access Service” ( within W iMAX Capability 20 attribute) will be used to indicate the service capability of ASN and V-CSN. Note that ASN, CSN can support more 21


Page - 86


than one capability in some situations. If supported, this parameter will be conveyed from the ASN to the V-CSN 1 and from the V-CSN to the H-CSN in the Access Request message. Once the MS is successfully authenticated by 2 the H-AAA and H-CSN has authorized Service(s), the Mobility access classifier may be passed to ASN through 3 Access Response message. Once the ASN obtains this information, it s tores this information locally and makes it 4 available to u se b y th e a ppropriate f unctional e ntity within ASN. D epending o n t he outcome o f t his c apability 5 exchange, ASN may o ffer Fixed, Nomadic or Mobility service to the mobile. It is the NAS that will make final 6 decision of whether or not to allow MS’s request and assign the appropriate service for this MS. 7

The following Figure and corresponding text provide the detailed procedure of this service negotiation solution. 8

CSN at V-NSP-

(AAA Proxy)ASN in NAP

(NAS)

CSN at H-NSP-

(AAA Server)

1. AAA Request(ASN Access Service ) 2. AAA Request

( ASN Access Service)( VCSN Access Service)

3. AAA ResponseMobility Access Classifier

4. AAA ResponseMobility Access Classifier

9

Figure 7-22 - Access Services Co-existence Negotiations and Selection Flow 10

1) During MS authentication phase, the AAA Request message is sent by the ASN destined to the H-AAA of 11 the MS via the AAA Proxy at the V-CSN. When no V-CSN is involved, the message will go from ASN to 12 H-CSN d irectly. I n p articular, A SN i ncludes t he “ASN A ccess Service” within W iMAX C apability 13 Attribute in the AAA Request to provide current ASN service capability information to the HAAA. If the 14 ASN does not include “ASN Access Service”, then it shall be defaulted by the HAAA as an ASN that only 15 supports Mobility services. The NAS also passes the Serving BS identification information to the H-AAA 16 in the same AAA Request message. If the MS is fixed or nomadic, the H-AAA checks if this BS belongs to 17 the network entry zone of the subscriber. If this check fails, then H-AAA can fail authorization step since 18 MS is not allowed to get service at this point of attachment. 19

Note that Mobility restriction information such as the mobility access classifier and the network entry zone 20 info in the subscriber profile MAY be configured over-the-air b y H -NSP for each subscription. The MS 21 MAY use t his i nformation i n an i mplementation s pecific manner ( for ex ample t o i nitiate n etwork en try 22 only at BSs that belong to the subscription network entry zone). 23

2) After r eceiving AAA Request message, t he V -CSN adds “ VCSN A ccess S ervice” w ithin WiMAX 24 Capability Attribute to this message and forwards the message to the H-AAA Server at the H-CSN. If the 25 V-CSN does not include “VCSN Access Service”, then i t shall be defaulted by the H-AAA as a V-CSN 26 capable of providing Mobility services only. 27

3) Once the H-AAA Server successfully authenticates and authorizes the MS services, the H-AAA returns the 28 AAA Response message to the NAS via the AAA Proxy at the V-CSN. The Authorized Services will be 29


Page - 87


included in the AAA Response message using the mobility access classifier info. I f the H-CSN does not 1 include mobility access cl assifier, then it shall be d efaulted b y the N AS as a n H-AAA a uthorizing o nly 2 Mobility services. The H-AAA will not authorize a Service that can’t be supported by the ASN. If the NAS 3 receives an AAA Response which requires i t to p rovide a service that i t does not support, then how the 4 NAS considers the AAA Response is up to local policies. 5

4) The A AA P roxy i n t he V -CSN will f orward t his AAA Response message t o t he ASN. T he A SN will 6 extract t he mobility acce ss c lassifier, store i t l ocally and make it a vailable to u se b y t he ap propriate 7 functional entity within the ASN. Depending on the outcome of this capability negotiation, the ASN will 8 offer fixed, nomadic or mobility services to the MS 9

7.3.13 AAA Framework profile for Ethernet Services 10 The AAA Framework i s fully applicable also for E thernet Services. In particular device authentication as well a s 11 user authentication may be used for authentication of MSs providing plain Ethernet connectivity with or without 12 VLAN support towards the customer equipment (modem style CPE device). 13

14

7.4 ASN Security Architecture 15

The s ecurity ar chitecture i nside th e A SN c onsists o f th e f ollowing f unctional e ntities, n amely, Authenticator, 16 Authentication Relay, Key Distributor and Key Receiver. Authenticator is defined per the Authenticator in the EAP 17 documentation [ 52]. A uthentication Relay i s de fined a s t he functional e ntity that r elays E AP p ackets without 18 snooping into or modifying the EAP packet via an Authentication Relay Protocol defined in Section 7.4.3 between 19 the Authentication Relay a nd th e Authenticator. K ey D istributor is d efined a s t he f unctional entity th at is a k ey 20 holder for both MSK and PMK resulting from an EAP exchange. The MSK is sent to the Key Distributor from the 21 home AAA server, and the PMK is derived locally from the MSK. Additionally, Key Distributor also derives AK 22 and creates AKID for an <MS, BS> pair and d istributes the AK and i ts context to the Key Receiver in a B S via 23 Context T ransfer p rotocol. Key Receiver i s the key holder for AK and is re sponsible for generation of IEEE Std 24 802.16e specified keys from AK. 25

The Authentication Relay and Key Receiver always reside in the BS. The Authenticator and Key Distributor are 26 usually c o-located. T here ar e t wo d eployments models: t he I ntegrated d eployment model an d S tandalone 27 deployment model. In the Integrated deployment model, the Authenticator and Key Distributor are collocated with 28 the Authentication Relay and Key Receiver and thus reside in the same BS as shown in Figure 7-23. 29

AuthenticationRelay

Key Receiver

Authenticator

Key DistributorBS

Context transferProtocol

Authentication RelayProtocol

30

Figure 7-23 - Integrated Deployment Model 31

In the Standalone deployment model, the Authenticator and Key Distributor are collocated together on a p hysical 32 functional e ntity o ther than t he BS a s shown in Figure 7-24. I t is p ossible to th ink a bout a n a rchitecture where 33 Authenticator and Key Distributor are not collocated but that model is not considered here. 34


Page - 88


AuthenticationRelay

Key Receiver

Authenticator

Key Distributor

Single DeviceBS

Authentication RelayProtocol

Context TransferProtocol

1

Figure 7-24 - Standalone Deployment Model 2

In th e I ntegrated d eployment model th e Authentication Relay a nd Context T ransfer P rotocols a re in ternal to th e 3 implementation. I n th e S tandalone d eployment model, a n A uthentication Relay P rotocol is d efined b etween 4 Authentication Relay and Authenticator for relaying EAP packet as shown in Figure 7-25. 5

EAP/Authentication Relay

ASN

BSs

EAP /PKMv2

MS

EAP / AAA

AAA Server

Supplicant AuthenticationRelay Authenticator Authentication

Server

6

Figure 7-25 - Authentication Relay Inside the ASN 7

Additionally, for both Integrated and S tandalone deployment models, the Context Transfer P rotocol is defined to 8 securely transfer t he k eying material n amely AK, a nd i t’s co ntext ( e.g., CMAC_KEY_COUNT, A K S equence 9 Number, AKID, AK lifetime, EIK, etc.) from the Key Distributor to the Key Receiver in the target BS to which an 10 MS doe s a H O a s s hown i n Figure 7-26. Since t he Integrated d eployment model i s a sub-set o f t he S tandalone 11 deployment model, this document just refers to Standalone deployment model. 12

BSsMS

Supplicant KeyReceiver

KeyDistributor

AuthenticationServer

MSK transferredAuthentication

AAA Server

EAP Exchange Generates MSK at MS and AAA Server

PMK & AK GeneratedContext Transfer

Protocol

ASNAK Cached

13

Figure 7-26 - AK Transfer Inside the ASN 14


Page - 89


7.4.1 Architectural Assumptions 1 The f unction o f a uthenticator a s mentioned i n [ 52] a nd EAP keying d raft, [ 61], is n ot s plit. All a uthenticator 2 functions are implemented in one place. 3

The authenticator and BSs belong to the same administrative entity. Communications between them is assumed to 4 be s ecure, e. g., v ia p roper encryption an d i ntegrity p rotection. T his i mplies t hat t he au thenticator an d B Ss s hare 5 secrets required for secure communications. The mechanisms regarding how these shared secrets are established are 6 outside the scope of this specification. In essence this document assumes that the BSs are like physical ports of an 7 authenticator as per the EAP keying draft. Figure 7-27 shows two variants, i.e., a single or multiple BS/port(s) per 8 Authenticator. 9

Authenticator Authenticator

BSs/Port

BSs/Ports

Peer(MS)

Peer(MS)

10

Figure 7-27 - Single Versus Multiple BS per Authenticator 11

7.4.2 Authenticator Domain and Mobility Domain 12 The architecture defines a co ncept of Authenticator Domain, which consists of one or more of BSs (stand alone or 13 Integrated BS) that are under the control of a s ingle Authenticator. All BSs within a given Authenticator Domain 14 SHALL forward EAP messages to and from the Authenticator o f the domain of a g iven subscriber. Each BS can 15 belong to more than one Authenticator Domain. 16

When an MS enters a network, t he BS forwards i ts EAP p ackets to the Authenticator o f t he given Authenticator 17 Domain, which becomes its Anchor Authenticator residing within a given trusted domain. The Anchor Authenticator 18 caches the PMK and related authentication i nformation for MS that enter t he network via o ne of t he BSs in the 19 domain, and retains this cached information until the MS re-authenticates with a different Authenticator (which then 20 becomes the new Anchor Authenticator for the MS). If the MSK/PMK lifetime is expired (e.g., the MS leaves the 21 network), t he cac hed i nformation S HALL b e d iscarded. E very MS i s, at a g iven t ime, an chored at ex actly o ne 22 Authenticator located within a NAP. Association between MS and Anchor Authenticator does not have to physically 23 match any association between MS and other ASN functions (e.g., page controller, FA). 24

The architecture also defines a concept of Mobility Domain, which consists of a set of BSs for which a single PMK 25 can be used to derive BS-specific AK and its contexts as the MS performs handoffs. A Mobility Domain MAY be 26 equal to a N AP, and maps to one or more Authenticator Domains. However, as the PMK SHALL be generated by 27 the Authenticator, the PMK CANNOT be shared across the Authenticator Domains within the mobility domain. 28

A Key Distributor belongs to a Mobility Domain, and there MAY be multiple Key Distributors in a domain, and 29 Figure 7-28 and Figure 7-29 show t he relationships b etween the two d omains and the Authentication Relay a nd 30 Context Transfer protocols in context of integrated and standalone models. 31


Page - 90


BS

Authentication Domain = ASN n

Mobility Domain = NAP

Authentication Domain = ASN 1

Authentication RelayProtocolContext TransferProtocol

BS

AuthenticationRelay

Key Receiver

Authenticator

Key Distributor

Authentication +Key Distributor

BS

BS

1

Figure 7-28 - Mobility and Authenticator Domains – Standalone Model 2


Page - 91


UnspecifiedMechanismContext TransferProtocol

Mobility Domain = NAP

AuthenticationRelay

Key Receiver

Authenticator

Key Distributor

Key Distributor

Authenticator

Key Receiver

AuthenticationRelay

BS

BS

Authentication Domain

Authentication Domain

1

Figure 7-29 - Mobility and Authenticator Domains – Integrated Model 2

7.4.3 Re-Authentication Procedure 3 The full re-authentication EAP exchange like the initial authentication EAP exchange is done via the authenticator 4 associated with the current serving BS. Typically, this MAY lead to a change of authenticator, if the current serving 5 BS is associated with a different authenticator than the one which is current acting as the authenticator for the MS. 6

The re-authentication MAY be initiated by either: 7

The t arget a uthenticator: I n this cas e, t he target Authenticator a utonomously in itiates a nd e xecutes t he full E AP 8 exchange authentication. Once the EAP exchange authentication is successfully completed, the target Authenticator 9 becomes a n Anchor Authenticator, a nd M AY s end t o t he s erving Authenticator an o ptional “RE-AUTH-IND” 10 message including the MS identity. Thus the serving Authenticator can free resources. 11

Or t he s erving Authenticator: I n t his c ase t he s erving ( current Anchor) Authenticator informs t he t arget 12 Authenticator t hat t he full E AP e xchange a uthentication i s r equired. T he r e-authentication is i nitiated b y a RE-13 AUTH-REQ message f rom the s erving t o t he t arget Authenticator. O nce t he E AP e xchange a uthentication i s 14 successfully completed, the target Authenticator sends a RE-AUTH-CONF message to the serving Authenticator so 15 that it can free resources. 16

7.4.4 Authentication Relay Protocol 17 In t he S tandalone model a t ransport pr otocol i s needed t o e xchange t he EAP P DUs be tween the Authentication 18 Relay and Authenticator as shown in Figure 7-30. 19


Page - 92


EAP

802.16

PKMv2

EAP

802.16

PKMv2

EAP

PHY

AAA

EAP

PHY

AAA

EAPEAPAuth Relay

Protocol

Auth Relay

Protocol

EAP/Auth Relay

ASN

BSs AAA Server

EAP/AAA

Authentication ServerAuthenticator

Authentication Relay

MS

EAP/PKMv2

Supplicant

1

Figure 7-30 - Authentication Relay Protocol 2

Also, the p rotocol SHOULD address al l the requirements placed by [52] on the EAP lower layer. Authentication 3 Relay Protocol MAY transfer EAP. 4

7.4.5 Context Transfer Protocol 5 When the MS handoffs between BSs that belong to the same mobility domain, the key receiver in the target BSs 6 need to be populated with AKs derived from the PMK stored in the Key Distributor if it has not expired. The Key 7 Distributor uses the Context Transfer protocol to populate AK in the Key Receiver in the target BS to which the MS 8 conducts HOs. 9

The C ontext T ransfer pr otocol6

Key Receiver Key Distributor: Context_Req 15

is a t wo-message e xchange b etween t he K ey D istributor an d t he K ey R eceiver, 10 consisting of an optional Request message and a mandatory Transfer message. The Context_Req message requests a 11 new AK from the Key Distributor, and the Context_Rpt message either delivers an AK, AKID, AK Lifetime, AK 12 Sequence Number and EIK or indicates a failure. The identity of the Key Distributor is determined based on the MS 13 identifier in the Context_Req message. This is depicted below: 14

Key Distributor Key Receiver: Context_Rpt 16

The following figures show example scenarios of how the Context_Req and Context_Rpt exchange is triggered. The 17 actual instance during a handoff when this transfer is triggered is controlled by ASN mobility management protocol. 18

6 It is e xpected th at C ontext Transfer P rotocol p rimitives will b e i mplemented in form o f T LVs th at will b e exchanged as part of intra-ASN and inter-ASN mobility management protocols.


Page - 93


MS Serving BSKey Receiver

Target BSKey Receiver

Anchor AuthenticatorKey Distributer

Continues

MOB_HO-IND

HO_Cnf

Context_Req

Context_Rpt

1

Figure 7-31 - Context_Rpt Triggered by MOB_HO-IND 2




Continues

RNG-REQ

Context_Req

Context_Rpt

MS Context Interaction

3

Figure 7-32 - Context_Rpt Triggered by RNG-REQ 4


Page - 94





Continues

MOB_MSHO-REQ

HO_Req

Context_Req

HO_Rsp

MOB_BSHO-RSP

HO_Cnf

MOB_HO-IND

Context _Rpt

1

Figure 7-33 - Context_Rpt Triggered by MOB_MSHO-REQ 2

In both the Integrated model and Standalone model, AK can be transferred to a Key Receiver that is not co-located 3 with the Key Distributor. Therefore, a secure association SHOULD exist between Key Receiver and Key Distributor 4 in order to secure the transfer of AK, etc. AK, AKID, AK Sequence Number and EIK are derived as per 802.16e 5 draft. T he B S up on r eceiving t he Context_Rpt message, d ecrypts the A K, A KID, AK Lifetime, A K S equence 6 Number, CMAC_KEY_COUNT and EIK etc., and stores them locally for future use. 7

Lastly, when MS does a handoff such that serving and target BSs are a ssociated with d ifferent Key Distributors, 8 Context Transfer protocol exchanges occur between the Key Distributors as shown in Figure 7-34. Any intermediate 9 Key Distributors just act as relay in such a situation. 10


Serving ASN-GW

Key Receiver

Auth ASN-GWKey Distributor

Anchor Authenticator

Target ASN-GWKey DistributorAuthenticator


Context_Req

HO_Cnf

MOB_HO-IND

Continues

Context_Rpt

HO_Cnf

HO_Cnf

Context_Req

Context_Rpt

11

Figure 7-34 - Context_Rpt Triggered by MOB_HO-IND 12


Page - 95


Considering t he T arget B S a ddress A nchor A uthenticator, i t i s necessary t o e xchange Anchor A uthenticator I D 1 information during HO preparation between Serving BS and Target BS. 2

7.5 Accounting 3

Accounting in WiMAX Forum® Network Architecture Release 1.0.0 will be based on RADIUS. Both offline (post-4 paid) an d online ( prepaid) accounting cap abilities ar e s upported. The acc ounting ar chitecture, p rotocols an d 5 procedures are described in the following sections. 6

7.5.1 Accounting Architecture 7 Accounting architecture is shown in Figure 7-35 below. The figure shows network elements for both offline and 8 online services. The figure also shows the network elements for Hot-lining support in the ASN. A description of 9 each entity is provided in the following sections. Within this figure, HA functional entity is only needed in Mobile 10 IP service. For Simple IP service, the HA functional entity is not applicable. 11

SS/MSS

HLA

CSN

R5

CSNASN

NAP+Visited NSP Home NSP

AAA Client/ActAgt

PPC/HLD

Visited AAA Server

PPS

Home AAA Server

AAA Client/ActAgt/

PPC/HLD

R3

HA

HA

12

Figure 7-35 - Accounting Architecture 13

7.5.1.1 AAA Server Requirements 14 The RADIUS based AAA Server SHALL follow the specification [23], [24], and [36]. 15

Upon receiving RADIUS Accounting-Request records from the ASN, the Visited RADIUS server SHALL forward 16 the RADIUS Accounting-Request records to the home network directly or via broker network(s). 17

7.5.1.2 ASN Requirements as AAA Client 18 ASN S HALL s upport R ADIUS b ased acco unting as d efined i n [ 24] an d [ 36]. The A AA Client S HAL co llect 19 accounting information from the Accounting Agents in the ASN. T he collected information SHALL be sent to the 20 Accounting Server (AAA Server) in the home CSN. T he accounting information SHALL be relayed to the VAAA 21 if one exists and MAY be sent through Broker AAA proxies. 22


Page - 96


7.5.1.3 HA Requirements as AAA Client 1 If t he H A s upports Accounting t hen t he H A SHALL support R ADIUS c lient a s s pecified i n [ 23] a nd RADIUS 2 Accounting as specified in [24] and [36]. The HA shall indicate i ts ability to support Accounting function when 3 authentication t he MIP r egistrations requests. If the H ome network wants the HA to report a ccounting then t he 4 home AAA server SHALL indicate to the HA to report accounting during the authentication of the MIP registration 5 request. 6

If instructed to report accounting, the HA SHALL forward accounting records to the home AAA server directly (if it 7 is located in the home CSN) or via the VAAA if it is located in the visited CSN. 8

7.5.1.4 Accounting Primitives 9 The following primitives are exchanged between an accounting agent and accounting client in cases where these 10 functions are not co-located. 11

7.5.1.4.1 Accounting Information Request 12 This primitive is sent from AAA client to accounting agent to configure accounting agent or request accounting 13 information. 14

7.5.1.4.2 Accounting Information Report 15 This primitive is sent from accounting agent to AAA client to report accounting information which can be triggered 16 by accounting information request or automatically report to AAA client per configuration. 17

7.5.1.4.3 Accounting Information Acknowledge 18 This primitive is sent from AAA client to accounting agent to acknowledge the receiving of accounting report. 19

7.5.2 Accounting Protocols 20

7.5.3 Offline Accounting 21 This section describes the off-line (post-paid) accounting procedures and the Usage Data Records (UDRs). 22

Packet data accounting parameters are divided into radio specific parameters (e.g., number of bytes/packets dropped 23 at the BS), and IP network specific parameters collected by the Serving ASN. The Serving ASN SHALL merge 24 radio specific parameters called Airlink Records with IP network specific ones to form one or more Usage Data 25 Records ( UDR). After merging, t he S erving ASN S HALL use R ADIUS a ccounting messages t o s end UDR 26 information to the home RADIUS Server (via the visited AAA server if the subscriber is roaming). The detailed 27 procedures for creating UDRs are described in the following sections. 28

7.5.3.1 Airlink Records 29 The ASN generates the following airlink records: 30

• An Active Start Airlink Record when the MS has connected the associated over-the air service flow. 31

• An Active Stop Airlink Record when the MS has released the associated over-the-air service flow. 32

7.5.3.2 ASN Procedures 33 The following events cause accounting action: 34

• R6 Connection Setup Airlink Record received over R6 reference point. 35

• Data service establishment on the ASN-GW. 36

• Data service termination on the ASN-GW. 37

• Reception of Active Start Airlink Record. 38

• Reception of Active Stop Airlink Record. 39

• Interim-Update record trigger. 40


Page - 97


• Stop record trigger. 1

• Time of day timer expiry. 2

• Hot-lining. 3

• Inter-ASN hand-off trigger. 4

• The location information for postpaid (Only location based postpaid accounting is specified in this release. 5 Location based prepaid will be specified in a later release). 6

• The QoS of the service flow or the session is changed. 7

Each individual session SHALL be accounted for independently. All UDR information is stored and transmitted per 8 assigned IPv4 address or IPv6 prefix, or per packet data flow. During the lifetime of the session, UDRs are created, 9 modified, maintained, copied, and released for each individual connection. The Serving ASN SHALL create one 10 UDR per R6 connection ID or other data path ID established for the MS. 11

The ASN closes a UDR when any of the following events occur: 12

• An existing service flow is deleted, denied, or failed. 13

• The ASN determines the packet data session has ended. 14

At an initial R6 connection establishment, a U DR is created and initialized from the R6 connection setup airlink 15 record. When there is a new R6 connection due to a handoff for an existing packet data session, or when there is a 16 new R6 connection for an existing packet data session, a UDR is created by copying data from a previous UDR. 17

During a inter ASN handoff either two R6 connections, or an R4 and an R6 connection, or two R4 connections with 18 the same SFID and MSID MAY exist momentarily due to the ASN bicasting. Since the MS can connect to only one 19 ASN for a given service flow, the ASN accounting procedures SHALL ensure that double counting between the 20 current and new (copy) never occurs despite the ASN bicasting of data to both service flows. 21

RADIUS accounting messages are generated from the information in the UDR. The Acct-Multi-Session-ID is used 22 to match different accounting records (Account Session IDs) across R6, R4 or both connections for a single packet 23 data session. One Acct-Multi-Session-ID for all R6 connections is maintained for a packet data session for each NAI 24 and IP pair within the same Visited CSN. The Account Session ID is used to match a single RADIUS Start and Stop 25 pair. A different Account Session ID is used for each R6 connection. 26

A new R6 c onnection du e t o i ntra-ASN handoff b etween B Ss SHALL r esult i n a new R6 C onnection I D a nd 27 Account Session ID. The MSID and SFID are used to select the proper UDR after an intra-ASN handoff. One R6 28 Connection I D M AY b e associated with multiple s imultaneous N AI, I P p airs in th e S erving ASN ( i.e., multiple 29 packet data sessions). 30

Airlink records are only associated with an R6 connection ID. The Serving ASN matches the R6 Connection ID in 31 the airlink record to the R6 Connection ID in the appropriate UDR(s). If more than one UDR matches, the actions 32 are applied to all UDRs. 33

Some events cause certain UDR fields to change in the middle of a session. When this happens, the ASN MAY send 34 a RADIUS Accounting-Request-Stop record to cap ture accounting data before the event, followed b y a R ADIUS 35 Accounting-Request-Start record with the new field values. I n fact, an ASN MAY send a RADIUS Accounting-36 Request-Stop and RADIUS Accounting-Request-Start anytime during a single session as long as no accounting data 37 is l ost. In these cases, the ASN SHALL send the same Acct-Multi-Session-ID in both the RADIUS Accounting-38 Request-Start and RADIUS Accounting-Request-Stop records. 39

7.5.4 QoS-based Accounting 40 The QoS-based accounting is charging on service session, not user connection as traditional accounting does. The 41 WiMAX® network is capable of support multiple services for one user simultaneously with appropriate QoS level. 42 The accounting function SHOULD be capable of separating one service session from others by characteristics of the 43 service such as TCP/UDP port, protocol type, etc. RADIUS acco unting messages, added with the information of 44 service session and QoS level, are generated in AAA client and sent to AAA server. 45


Page - 98


7.5.5 Online Accounting (Prepaid) 1 This section describes the online (prepaid) accounting procedures in the WiMAX® network. The prepaid packet data 2 service allows a user to purchase packet d ata service in advance based on volume or duration. Account status is 3 stored on a prepaid server (PPS) that is located in the user’s home network and accessed via the HAAA server. To 4 provide service to roaming prepaid users, the visited ASN or CSN needs to support the prepaid service and the local 5 and broker AAA servers need to forward the new prepaid accounting attributes transparently to and from the home 6 AAA server. The HAAA server and the prepaid server could be collocated or could be separate entities (see Figure 7 7-35). 8

From the ASN perspective, the HAAA and the prepaid server are indistinguishable. Although this document does 9 not make assumptions about the prepaid server – HAAA interface, the call flows MAY show the prepaid server and 10 the HAAA as separate entities. 11

The prepaid billing solution can provide the following services: 12

a) Simple IP based service metering in real time. 13

b) Undifferentiated M obile I P s ervices in r eal ti me with s upport f or multiple Mobile I P s essions p er u ser. 14 “Undifferentiated” means that all the Mobile IP sessions for a single user will be rated equally. 15

c) Rating measurement based on data volume and/or call duration. Data volume is measured as total octets, 16 uplink o ctets, downlink o ctets, total packets, uplink packets or downlink packets and total duration. The 17 rating function can be done either by the prepaid client or prepaid server. 18

Prepaid service for multiple simultaneous data sessions is also allowed. As the network does not have any a priori 19 knowledge o f t he u ser us age b ehavior, t he s olution i s b uilt o n an i terative au thorization p aradigm. T he p repaid 20 server will ap portion a f raction of s ubscriber’s b alance into a quota, each time an authorization request is made. 21 Multiple sessions from the same user will each obtain their own quota, each session needs to seek reauthorization 22 when the previously allocated quota is depleted thus minimizing any leakage. The granularity and the magnitude of 23 the quota are implementation details of the prepaid server; therefore, it is beyond the scope of this specification. The 24 limitation with this method is as the number of session increases, the quota for each session will be diluted. The user 25 might need to close some sessions in order to collect all remaining quota that was allocated to his active sessions. 26

In order to support prepaid packet data service the ASN and/or the CSN SHALL support the prepaid client (PPC) 27 function an d t he p repaid s erver ( PPS) f unction M AY b e co llocated w ith t he H ome RADIUS s erver. I n t his 28 specification, t he p repaid p acket d ata service s upports a s et o f cap abilities as d escribed i n t he next s ection. 29 Additional capabilities MAY be supported in future revisions of this specification. When the prepaid account of user 30 is depleted, the P PC SHALL s top t he o nline acco unting service. I f t he user al so has a pos tpaid a ccount a nd i s 31 authorized to hand off off-line accounting base on profile or rule, the PPC of the ASN can notify the AAA client of 32 ASN that SHALL create the UDR and send an off-line RADIUS accounting-request to AAA server but the service 33 flow SHOULD not be terminated. 34

7.5.5.1 Online Accounting Capabilities 35 In this revision of the specification, the following prepaid capabilities are supported: 36

• Volume based prepaid, with quota assigned at a service flow level if the PPC resides in the ASN. 37

• Volume based prepaid with quota assigned at the packet data session level (IP/NAI) if the PPC is located in 38 the CSN (HA). 39

• Duration based prepaid, with quota assigned at a service flow level if the PPC resides in the ASN. 40

• Duration based prepaid, with quota assigned at the packet data session level (IP/NAI) if the PPC is located 41 in the CSN (HA). 42

• Ability for the Home AAA/PPS to allow/deny/select a PPC based on the Home AAA/PPS policy, user 43 profile, PrePaidAccountingCapability (PPAC) VSA and the Session Termination Capability (STC) VSA of 44 the ASN and/or the CSN (HA). 45

• The prepaid packet data service is based on the RADIUS protocol. 46


Page - 99


• Home AAA/PPS ability to manage the prepaid packet data service when the quota allocated to a PPC is 1 consumed or a pre-determined threshold value is reached, through triggers provided to the PPC. 2

• The capability of the PPC based in the ASN to support VolumeQuota and a tariff switch time interval 3 concurrently per service flow. The capability of the PPC based in the CSN to support VolumeQuota and a 4 tariff switch time interval concurrently per packet data session. 5

• The capability in the PPC and the Home AAA/PPS to provide tariff switch volume based prepaid packet 6 data service, with tariff switch trigger controlled at the Home AAA/PPS. This capability includes: 7

• Charged by volume, different tariff for different time of a day. 8

o Charged by volume, different tariff for different volume consumed, and the PPS SHALL allocate the 9 quota so that the quota does not overlap the two charging rates. 10

o Charge by volume, different tariff for different QoS. When the QoS is changed, the PPC can report 11 the consumed volumes before the change and the PPS SHALL allocate the new quota for new QoS. 12

Tariff switching with duration based prepaid at the Home AAA/PPS. This capability includes: 13

• Charged by duration, different tariff for different time of a day. 14

• Charged by duration, different tariff for different duration consumed, and the PPS SHALL allocate the 15 quota so that the quota does not overlap the two charging rates. 16

• Charged by duration, different tariff for different QoS. 17

• Account balance updated by the Home AAA/PPS according to the quota consumed by the user and 18 reported by PPC and the tariff information in the user’s profile. 19

• The prepaid account SHALL be reconciled at the Home AAA/PPS at inter-ASN handoff. 20

7.5.5.2 ASN Requirements for Prepaid 21 If the ASN supports a PPC, it SHALL also support Dynamic Authorization with RADIUS [48] and Registration 22 Revocation for Mobile IPv4 capabilities [45]. The ASN is referred to as a prepaid capable ASN, a nd the p repaid 23 capability is based on the following principles: 24

• The ASN includes in the RADIUS Access-Request message to the Home RADIUS server/PPS, the PPAC 25 VSA and the STC VSA. The values for each VSA are set appropriately and will be specified in the stage 3 26 specifications. 27

• Except for quota initialization for the Initial service flow (ISF), which is included in the RADIUS Access-28 Accept message by the Home RADIUS server/PPS, on-line quota update operation is performed by the 29 prepaid capable ASN using on-line RADIUS Access-Request/Accept messages with Service-Type (6) set 30 to ”Authorize Only”. The on-line RADIUS Access-Request SHALL contain the PrePaidAccountingQuota 31 (PPAQ) VSA. 32

• The Home RADIUS Server/PPS initializes a quota for a user at authentication and authorization if it 33 determines that the user is a prepaid user with positive prepaid balance and that the home network policy 34 allows the ASN to provide prepaid service. The initialized quota is sent to the PPC in the RADIUS Access-35 Accept message associated with the creation of the Initial service flow. The RADIUS Access-Accept 36 message includes the PPAQ and PPAC VSAs. 37

• The processing of off-line Accounting Request/Response messages proceeds independent of prepaid 38 service. 39

• RADIUS Accounting (Stop/Start) messages caused by events such as parameter change, time of the day 40 change, intra-ASN handoff do not cause the prepaid counters (such as VolumeQuota used, DurationQuota 41 used etc.) to be re-set to zero. 42

If the RADIUS Access-Accept message includes the initial quota and contains the Service Profile a ttribute which 43 indicates that the user is al lowed to establish multiple service flows, the prepaid capable ASN MAY immediately 44


Page - 100


initiate an on-line RADIUS Access-Request message to request pre-initialization of quota for any additional service 1 flow that the user MAY establish. 2

If the user requests establishment of a service flow for which quota pre-initialization is not done, the ASN sends an 3 on-line RADIUS Access-Request message to request initialization of quota. 4

The PrePaid capable ASN and the Home RADIUS/PPS MAY support tariff switch for volume based PrePaid packet 5 data service. 6

7.5.5.3 CSN Requirements for Prepaid 7 The prepaid capable CSN SHALL support prepaid for packet data sessions identified by IP/NAI. 8

The p repaid capable C SN S HALL s end a R ADIUS Access-Request message t o t he H ome R ADIUS/PPS u pon 9 receiving the in itial R RQ, r e-registration an d updated ( new CoA) RRQ. T he R ADIUS Access-Request m essage 10 SHALL include the additional VSAs: PPAC and STC. 11

If t he R ADIUS A ccess-Accept m essage f rom t he H ome R ADIUS/PPS co ntains t he P PAC V SA i ndicating t hat 12 prepaid acco unting SHOULD b e p rovided f or t he user, t he R ADIUS Access-Accept message S HALL i nclude a 13 PPAQ VSA with an initial quota. 14

If both DurationQuota and TariffSwitchInterval are received for the same prepaid packet data session, the prepaid 15 capable CSN SHALL discard the T ariffSwitchInterval an d S HALL provide prepaid b ased o n the DurationQuota 16 only. 17

If t he P TS V SA is r eceived, i t SHALL i nclude t he T ariffSwitchInterval ( TSI) Sub-Type, a nd M AY include the 18 TimeIntervalafterTariffSwitchUpdate t imer ( TITSU) S ub-Type. T ITSU S ub-Type M AY be i ncluded when more 19 than one t ariff switch b oundary e xists, and the user M AY not reach the VolumeThreshold b efore the next tariff 20 switch b oundary i s c rossed. T he pr epaid c apable C SN S HALL monitor bot h t he V olume a nd t he D uration 21 concurrently to support tariff switching. The detailed accounting procedures for various prepaid services (Volume-, 22 Duration- and Tarrif-Switched-base) are specified in the stage 3 of this specification. 23

7.5.6 Hot-Lining 24 The Hot-lining feature provides a WiMAX® operator with the capability to efficiently address issues with users that 25 would otherwise be unauthorized to access packet data services. When a p roblem occurs such that a user may no 26 longer be authorized to use the packet data service, a wireless operator using this feature MAY hot-line the user, and 27 upon the successful resolution of the problem, return the user’s packet data services to normal. When a user is hot-28 lined, their packet data service is redirected to a Hot-line Application (HLA) which notifies the user of the reason(s) 29 that they have been hot-lined and offers them a means to address the concerns meanwhile blocking access to normal 30 packet data services. Reasons for hot-lining a user are: prepaid users whose account has been depleted; or users who 31 have billing issues such as expiration of a credit card; or users who have been suspected of fraudulent use. 32

As a result, hot-lining performs the following four fundamental activities: 33

• Blocking normal packet data usage. 34

• Notifying MS that packet data usage is blocked. 35

• Directing MS to rectify blockage. 36

• Restoring normal operations when the User has rectified issues that triggered the hot-lining of their service. 37 Or, 38

• Terminate service if the user failed to address the issues that triggered the hot-lining of their service. 39

Hot-lining would help provide a consistent user experience for all users, irrespective of which MS application is 40 using t he p acket s ervice. T his i ncludes p reventing n egative u ser ex perience r esulting f rom ar bitrarily b locking 41 packet data service without notifying the MS of packet data block and a mechanism to rectify the blockage. Hot-42 lining would further p rovide c onsistency a cross all applications t hat utilize the p acket d ata s ervice p lus it would 43 lower operating costs. 44


Page - 101


7.5.6.1 Hot-Lining Capabilities 1 The following section describes the general hot-line capabilities supported for this release: 2

a) Hot-lining is supported for both CMIP and PMIP operations both at the ASN and the CSN. 3

b) Hot-lining is supported for Simple IP operation at the ASN or CSN. 4

c) A user can be hot-lined at the start of their packet data session or mid-session as described below: 5

Active-Session Hot-lining:

The user starts a packet data session. In the middle of the session it is hot-lined and after the account is reconciled by some manner, the hot-lining status of the session is removed. The hot-lining is done with RADIUS Change of Authorization (COA) message.

New-Session Hot-lining:

The user’s session is hot-lined at the time of packet data session establishment. In this scenario the RADIUS Access-Accept message is used to hot-line the session.

d) Similarly, hot-lined status can be removed mid-session or at the start of a new session. 6

e) There are two methods in which the HAAA indicates that a user is to be hot-lined: 7

Profile-based Hot-lining

The HAAA sends a hot-line profile identifier in the RADIUS message. The hot-line profile identifier selects a set of rules that are pre-provisioned in the Hot-line Device (HLD) that cause that user’s packet data session to be redirected and/or blocked.

Rule-based Hot-lining

The HAAA sends the actual redirection-rules (HTTP or IP) and filter-rules in the RADIUS messages that cause the user’s packet data session to be redirected and/or blocked.

f) In or der t o pr operly a ccount f or t he h ot-lining s tate o f t he u ser, th e u ser’s hot-line state S HOULD b e 8 recorded in the accounting stream. 9

The following capabilities are not covered by this specification but are described in so far that they are needed to 10 implement a complete hot-lining solution: 11

a) The trigger(s) that cause an operator to hot-line a user is not in scope for this specification. These triggers 12 could come from a number of sources such as a billing system, fraud detection system, etc. 13

b) The means to notify the HAAA that a user is to be hot-lined is not in scope for this specification. 14

c) The means by which the user is notified that they have been hot-lined is not in scope of this specification. 15 Typically, the user will be notified that they have been hot-lined via their browser or other means. 16

d) The means by which the user interacts with the system to correct the symptoms that caused them to be hot-17 lined are not in scope for this specification. 18

e) The means by which the system notifies the HAAA that user need not be hot-lined, that their packet data 19 session is to be returned to normal is not covered as part of this specification. 20

f) The details of what happens when the ASN or CSN performs Profile-based Hot-lining are out of scope. It 21 is assumed that the user’s traffic is blocked and that the user gets notified. 22

When the packet data session is hot-lined some IP flows will be blocked and some IP flows will be redirected. The 23 intent of the redirection is not to continue the normal operation of the flow but rather to provide information to the 24 Hot-line application so that the Hot-line application can determine how to notify the user of their hot-lined state. 25

7.5.6.2 Hot- Lining Operation 26 Hot-lining involves the following packet data network entities (Figure 7-36): 27

• Visited/Home CSN. 28


Page - 102


• ASN. 1

• HAAA. 2

The CSN and/or ASN contain a Hotline Device (HLD) that implements the hot-lining rules requested by the HAAA. 3 The role of the VAAA with respect to Hot-lining is to act as proxy and as such will not be discussed further. 4

Hot-liningApplication

(not in scope)

AAA-Hot-Linesignalling

(not in scope)HAAA

CSN HotlineDevice

ASN HotlineDevice

RADIUS

RADIUS

Packetdata

Packetdata

Packetdata

Mobile-Hot-lining Application interaction: e.g., Web(not in scope)

MS

5

Figure 7-36 - Hot-Lining Operation 6

Hot-lining a lso i nvolves t he Hot-Line Application ( HLA). T he H ot-Line Application i s a functional e ntity t hat 7 performs the following roles: 8

• Determines when the user SHOULD be hot-lined. 9

• Initiates the hot-lining signaling with the HAAA. 10

• Hot-lined flows are redirected to the Hot-Line Application. 11

• Responsible for initiating notification of the hot-line status to the MS. This could be done via a delivery of 12 an HTML page to the subscribers’ browser or via some other means. 13

• Provides a mechanism for the user to rectify the issue that triggered hot-lining. 14

• Upon successful resolution of the problem, return the user back to normal operating mode. 15

• Upon unsuccessful resolution of the problem, terminate the user’s packet data session. 16

The implementation o f t he Hot-Line Application is not within scope o f th is document. T he in terface between the 17 Hot-Line Application and the various entities is out of scope. 18

The Hot-Line Application can reside over multiple servers in the network. For example, the Hot-Line Application 19 could reside in its entirety on a web server. Or certain parts of Hot-line Application can reside on ASN or CSN as 20 shown in Figure 7-36. 21

Hot-lining of a user’s packet data service starts when the Hot-Line Application determines that the user’s service is 22 to be hot-lined. This determination is entirely deployment specific and can be a r esult of many factors. Details are 23 not in scope for this document. 24


Page - 103


To initiate Hot-lining of the user, the Hot-Line Application will notify the HAAA that the user is to be hot-lined. 1 The m ethod of n otification i s ou t of s cope. U pon r eceiving t he notification from t he Hot-Line Application, th e 2 HAAA records the hot-lining state against the user record. 3

The HAAA will determine if the user is currently in-service or out-of-service. If the user is in-service the HAAA 4 initiates the Active-Session Hot-Lining procedure, if the user is out-of-service the HAAA initiates the New-Session 5 Hot-Lining procedure. 6

Hot-lining requires that the Hot-lining Device be able to support Profile-based Hot-lining and or Rule-based Hot-7 lining. When support for Active Session Hot-lining is not provided the operator could utilize RADIUS Disconnect 8 Message to terminate the user’s session or specify a time period after which the session would be terminated by the 9 Hot-lining Device. To participate in Hot-lining an access device (ASN-GW/FA or HA) SHALL advertise its Hot-10 lining capabilities using the Hot-line Capability VSA sent in a RADIUS Access-Request message. The HAAA uses 11 the contents o f the Hot-line Capability VSA and other local policies to determine which access device will be the 12 Hot-lining Device for the session. 13

The hot-line signaling for a given packet data session is communicated by the HAAA to the Hot-line Device by 14 sending the Hot-Line Profile ID VSA; or by sending HTTP/IP Redirection Rule VSAs and Filter Rule VSAs. 15

7.5.7 Accounting Extensions for Ethernet Services 16 The accounting extensions for Ethernet Services are completely described and specified in the Stage 3 text. 17

7.6 QoS 18

Following procedures are defined: 19

(1) Pre-provisioned service flow creation, modification, and deletion. 20

(2) Initial Service Flow creation, modification and deletion. 21

(3) QoS policy provisioning between AAA and SFA. 22

(4) Network initiated dynamic service flow handling. 23

(5) MS initiated dynamic service flow handling. 24

7.6.1 Introduction and Scope 25 The scope of the QoS section is focused on the WiMAX® radio link connection. QoS specific treatment in the fixed 26 part of t he acces s a nd co re networks are implementation specific and ar e not described. As a result, t his release 27 makes no guarantees concerning end-to-end QoS. 28

The IEEE Std 802.16 defines a QoS framework for the air interface. This consists of the following elements: 29

• Connection-oriented service. 30

• Five data delivery services at the air interface, namely, UGS, RT-VR, ERT-VR, NRT-VR and BE. 31

• Provisioned QoS parameters for each subscriber. 32

• A policy requirement for admitting new service flow requests. 33

Under the IEEE Std 802.16, a subscription could be associated with a number of service flows characterized by QoS 34 parameters. T his i nformation i s pr esumed t o be pr ovisioned i n a s ubscriber management s ystem ( e.g., AAA 35 database), or a p olicy server. U nder t he static service model, the s ubscriber s tation is not allowed to change the 36 parameters of provisioned service flows or create new service flows dynamically. Under the dynamic service model, 37 an MS or BS MAY create, modify or delete service flows dynamically. In this case, a dynamic service flow request 38 (triggered using mechanisms not specified in IEEE Std 802.16) is evaluated against the provisioned information to 39 decide whether the request could be authorized. More precisely, the following steps are envisioned in the IEEE Std 40 802.16 for dynamic service flow creation: 41

a) Permitted service flows an d as sociated Q oS p arameters ar e p rovisioned for each s ubscriber v ia t he 42 management plane. 43


Page - 104


b) A service flow request initiated by the MS or BS is evaluated against the provisioned information, and the 1 service flow is created if permissible. 2

c) A service flow thus created transitions to an admitted, and finally to an active state either due to BS action 3 (possible un der bot h static a nd d ynamic service models) or du e t o MS a ction ( possible u nder d ynamic 4 service model). Transition to the admitted state involves the invocation of admission control in the BS and 5 resource reservation, and transition to the act ive state involves actual resource assignment for the service 6 flow. T he s ervice flow can directly tr ansit from p rovisioned s tate to a ctive s tate without going th rough 7 admitted state. 8

d) A service flow can also transition in the reverse from an active to an admitted to a provisioned state. 9

e) A dynamically created service flow MAY also be modified or deleted. 10

This specification extends the QoS framework established in the IEEE Std 802.16 to the WiMAX Forum® Network 11 Architecture reference architecture. This specification does not address the provisioning of QoS in the access and 12 core networks. There are many possibilities for enforcing QoS in L2 and L3 networks, and operators MAY require 13 specific L2 and L3 interfaces in ASN network elements to use known methods for mapping subscriber traffic onto 14 these networks. 15

7.6.2 QoS Functional Elements 16 Based on the IEEE Std 802.16 and the Stage 2 architectural reference model, the QoS functional model includes the 17 following elements, as illustrated in Figure 7-37. 18


Page - 105


VAAA

HAAAPF

(PCRF)AF

V-NSP policy data base

PF(PCRF)AF

Visited NSP

MS R1

ASN

SFM

Data Path Function

Admission Control

Local Resouse

InfoR6

Local policy database

R4

Serving SFA Function

PCEF / Anchor-SFA Function

R3 R3

SFA

R5R5

H-NSP policy data base

Home NSPSubscriber QoS profile

LPF

1

Figure 7-37 - QoS Functional Elements 2

a) MS and A SN. The WiMAX® network SHALL support A SN-initiated creation of s ervice flows. An MS 3 MAY, but is not required to, have this capability (the MS must, however, respond appropriately to ASN-4 initiated service flow actions). 5

b) The ho me p olicy function corresponds t o t he P CRF function which is b ased o n t he P CC framework 6 specified in [88]. The PCRF and its associated p olicy database belong into the h ome NSP. Maintained 7 information includes H-NSP's general policy rules as well as application dependant policy rules. The PCRF 8 is in charge to evaluate service requests against these policies. The MS directly communicates with the AF 9 using a pplication la yer c ontrol p rotocols, a nd th e A F M AY i ssue W iMAX s ervice flow tr iggers to th e 10 PCRF as a result in roaming case, the AF could be located at the H-NSP as well as at the V-NSP where the 11 corresponding PF’s are triggered. The PCRF in the V-NSP enforces the visited operator policies regarding 12 QoS au thorization r equested by t he h ome o perator f or a certain s ervice(s) as i ndicated b y t he r oaming 13 agreement. The interface between the V-PCRF and H-PCRF is undefined in this release of specification. 14

c) AAA server holds the user's QoS profile and associated policy rules. They are downloaded to the SFA at 15 network e ntry a s p art o f t he a uthentication a nd a uthorization p rocedure. A lternatively t hey ca n b e 16 provisioned in the PCRF. In the former case, the SFA evaluates the forthcoming service request against the 17 user profile. In the latter case, it is up to the home PCRF to do so. Further, the AAA may update user’s QoS 18


Page - 106


profile while a subscriber is attached to the network. In such a case, the AAA will send the complete profile 1 replacing the existing one in the SFA. The SFA SHALL adapt current service flows according to the update 2 provided by the AAA b y ei ther creating new flows or de leting or modifying existing flows as needed i f 3 required resourced are available. 4

d) A S ervice F low Ma nagement ( SFM) l ogical en tity in t he A SN. T he S FM en tity i s r esponsible f or t he 5 creation, a dmission, a ctivation, modification a nd de letion of 802. 16 service f lows. It c onsists o f a n 6 Admission C ontrol ( AC) f unction, a nd a ssociated lo cal r esource in formation. T he AC is used to d ecide 7 whether a new service flow can be admitted based on existing radio and other local resource usage. The 8 precise definition of the admission control functions is left to implementations. The SFM entity is always 9 located in the BS. 10

e) Service Flow Authorization (SFA) logical entities in the ASN. The SFA is separated into an Anchor-SFA 11 and a S erving-SFA where these entities might be located on different ASNs but could also be co-located. 12 The Anchor-SFA is responsible for evaluating any service request against user’s QoS p rofile in the case 13 when it is downloaded from the AAA. For a given ASN/NAP there exists an anchor SFA assigned to each 14 MS. T he anchor SFA is co-located with the Authenticator. The Serving-SFA is responsible for applying 15 QoS policy for that MS. The identity of the serving SFA, if different from the anchor-SFA, SHALL be 16 known by the anchor SFA at all times. Similarly, the serving SFA SHALL know the identity of the anchor 17 SFA. The anchor-SFA MAY also perform ASN-level policy decisions using a local policy database and an 18 associated Local Policy Function (LPF). The LPF can also be used to enforce admission control based on 19 available resources. The Anchor SFA is responsible for interfacing with the PCRF to enforce QoS based on 20 policy rules, to relay QoS related policies to the Serving SFA, and mapping the requested QoS to the SF-21 level QoS. A serving SFA SHALL be in the bearer path towards the SS, but only the signaling interactions 22 for SFA are in the scope of this document. The Anchor-SFA function corresponds to the A-PCEF function 23 if the dynamic QoS based on PCC framework is supported [88]. 24

f) A network management system (not shown) that allows administratively provisioning service flows. 25

In cas e t he Q oS p rofiles a nd as sociated p olicies ar e d ownloaded f rom t he AAA t o t he S FA t hey S HALL b e 26 expressed as depicted in the s tage 3 part of the present specification. Based on service provider requirements, the 27 provisioned information MAY include user priority, which is used to enforce relative precedence in terms of access 28 to r adio r esources s o t hat d ifferentiated s ervice cat egories ( e.g., g old, s ilver, an d b ronze) acr oss u sers ca n b e 29 realized. For example, t he user p riority MAY be taken into account i n s ituations where the service flow requests 30 across all users exceed the radio resource capacity and therefore a subset of those has to be selected for rejection. 31

The scope of the provisioned QoS profile is assumed to be specific to the MAC connections at the air interface. In 32 other words, t his p rofile d oes n ot imply s pecific QoS t reatment i n t he wireless b ackhaul o f t he acces s an d co re 33 networks. The latter would depend on the available QoS mechanisms in the fixed networks. 34

7.6.3 Triggers 35 The p rovisioned Q oS p rofile s erves t o au thorize d ynamic r equests i nitiated b y t he MS o r t he network. T hese 36 dynamic requests (creation, admission, activation as well as modification and deletion of service flows) MAY result 37 from different types of triggers including the ones described in the following subsection. 38

7.6.3.1 Pre-Provisioned Service Flows 39 A set of service flows can be created (in provisioned, admitted or active state depending on the received profile 40 parameters as specified in [54]) after a MS registers with the WiMAX network, before any subscriber data begins 41 flowing. This capability is realized by including the description of the service flows to be created. 42

7.6.3.1.1 Non-PCC based mode 43 If PCC framework is not present, pre-provisioned service flows are handled as follows. 44

If the user's QoS profile has been downloaded from the AAA during the authentication procedure of the network 45 entry, the Anchor-SFA initiates the creation of all the pre-provisioned service flow in the proper state according to 46 the profile provided by the AAA. Note that this MAY include not only pre-provisioned and dynamic SFs which has 47 already been known to the Anchor-SFA during the initial entry of MS, but also SFs which are to be created by the 48 update, as MS need to be informed regarding the complete profile. SFs marked with the “Active” flag SHALL be 49


Page - 107


activated i mmediately a fter s uccessful n etwork en try. T he M S o r A SN may ch ange t he s tate o f a s ervice f low 1 between the Provisioned, Admitted and Active state. In addition the ASN may change properties of services flows 2 (in acco rdance with I EEE802.16e), cr eate o r r emove service flows when t he AAA p rovides i t with a co mplete 3 updated set of parameters for pre-provisioned SFs. Message flows detailing these operations are provided in sections 4 7.6.5.1. 5

7.6.3.1.2 PCC based mode 6 If PCC framework is present, pre-provisioned service flows are handled as follows. After successful MS registration 7 with the WiMAX network, an anchor SFA SHALL be assigned, and its location updated with the associated PCRF 8 entity, unless the PCRF is aware of the anchor SFA through other means. Further details on pre-provisioned flow 9 operation can be found in section 8.1.1 of [88]. 10

7.6.3.2 Dynamic Service Flows 11

7.6.3.2.1 Non-PCC based mode 12 Dynamic Service Flow control in the absence of the PCC framework supports both network initiated SF handling as 13 well as MS initiated SF handling. Network initiated SF handling is mandatory to be supported while MS initiated SF 14 handling is an optional feature. The dynamic creation, deletion or modification of service flows are triggered by the 15 Network or by the MS. The ASN will perform the policy decision based on the information received by the AAA. 16 Note that policy decisions based on information from an application function is not supported as the CSN will not be 17 involved in the creation and deletion of these kinds of SFs. An MS may initiate a Dynamic Service Flow creation at 18 any time after a successful network entry. Message flows detailing these operations are provided in sections 7.6.5.2 19 through 7.6.5.5. 20

7.6.3.2.2 PCC based mode 21 Dynamic Service Flow control based on the PCC framework is an optional feature and is described in [88]. It allows 22 to perform pol icy control based on application related information and to provide appropriate charging attributes. 23 Network initiated SF handling is mandatory to be supported as far as the PCC framework is supported. MS initiated 24 SF handling is an optional feature in any case. The dynamic creation, deletion or modification of service flows are 25 triggered by the PCRF or by the MS. Details on these operations can be found in [88]. 26

In the PCC framework the Policy Function located in the CSN corresponds to the PCRF function. The A-PCEF is an 27 additional functionality exchanging bearer related triggers with the SFA. 28

7.6.4 Messages 29

7.6.4.1 Message types 30 The following sets of abstract messages are required to convey triggers, initiate service flow actions, request policy 31 decisions, download policy rules, and update MS location: 32

a) Resource-Reservation ( RR): RR_Req and RR_Rsp messages a re e xchanged b y t he a nchor S FA a nd t he 33 serving SFA (if different from anchor) to trigger creation an d d eletion as well as t o ch ange the state of 34 service flows. 35

b) Data Path Control Message: Path_Reg_Req/Path_Dereg_Req and Path_Reg_Rsp/Path_Dereg_Rsp 36 messages are exchanged by the Serving SFA and SFM to trigger creation and deletion of the Data Path. 37

c) Path_Modification_Req, Path_Modification_Rsp and Path_Modification_Ack messages are exchanged by 38 the Serving SFA and SFM to adapt as well as to change the state of service flows. In addition, Data Path 39 specific information required for the SFs are included. 40

7.6.4.2 Trigger Points for Dynamic SFs 41 Possible trigger points are the SFM, o r the Anchor-SFA. Specifically, t he t rigger point i s t he SFM when t he M S 42 generates e xplicit activate or deactivate r equest. S imilarly, t he anchor S FA i s t he t rigger p oint when e ither a n 43 updated set of PPSFs is received from the AAA or changes are initiated by the PCC framework. The admission 44 control function is located in the SFM in all cases. 45


Page - 108


7.6.5 QoS-Related Message Flow Examples 1 In this subsection, the control flows are illustrated for service flow creation and deletion, and updating of the SFA 2 location. In all these examples, it is assumed that there is a security association between communication entities, and 3 suitable retransmission mechanisms are implemented to ensure reliable communication. 4

7.6.5.1 Non-PCC based Pre-Provisioned Service Flows 5 This section pertains to when the PCC framework is not present. 6

Figure 7-38 shows t he procedure of pr e-provisioned SF cr eation initiated b y the a nchor S FA right after t he 7 successful completion of MS registration. SFs SHALL be created according to user’s QoS profile received from the 8 AAA. 9

10

MS SFM Anchor SFA

Path_Reg_Rsp

Path_Reg_Req

Apply Admission Control

Apply Policies

DSA-Request

DSA-Response

Registration Complete

Registration Complete may be detected by Access-Accept from AAA

Path_Reg_AckDSC-Ack

11

Figure 7-38 - Pre-Provisioned Service Flow Creation 12

Figure 7-39 shows t he cas e where AAA sends a n update o f t he p re-provisioned S F p rofile. I n s uch a c ase, t he 13 Anchor SFA will receive complete QoS profile which replaces the current one. The Anchor-SFA SHALL update the 14 SFs accordingly if required resources are available. This may result in different messages as the updated QoS profile 15 could request to delete or modify existing SFs or to create new SFs. 16


Page - 109


MS SFM Serving SFA Anchor SFA

DSA/DSC/DSD-Request

DSA/DSC/DSD-Response Path_Reg/Dereg/

Modification_Rsp

Path_Reg/Dereg/Modification_Req


RR_Req (Create/Modify/Delete)

Apply Policies

RR_Rsp

AAA

Update of subscribers QoS profile

CoA-Request(QoS profile update)

CoA-Resp.(QoS profile updated)

Path_Reg/Dereg/Modification_Ack

DSC-Ack

RR_Ack

1

Figure 7-39 - Update of Pre-Provisioned Service Flow 2

Please refer to [88] for message flows regarding the handling of pre-provisioned service flows in the case when PCC 3 framework is present and active. 4


Page - 110


7.6.5.2 Service Flow Creation by the ASN 1 Figure 7-39 shows SF creation by the ASN. SF creation by the ASN may appear because of a trigger from the PCC 2 framework or by AAA in case of QoS user profile update. 3


DSA-Response

DSA-AckPath_Reg_Rsp


RR_Response(create SF)

DSA-Request

Path_Reg_Req

RR_Request(create SF)

Path_Reg_Ack

Trigger from PCRF or AAA

RR_Ack

4

Figure 7-40 - Service Flow Creation by ASN 5


Page - 111


7.6.5.3 Service Flow Deletion by the ASN 1 Figure 7-41 shows SF deletion by the ASN. SF deletion by the ASN may appear because of a trigger from the PCC 2 framework or by AAA in case of QoS user profile update. 3


DSD-Response

Path_DeReg_Rsp

RR_Response(delete SF)

DSD-Request

Path_DeReg_Req

RR_Request(delete SF)

Path_DeReg_Ack


RR_Ack

4

Figure 7-41 - Service Flow Deletion by ASN 5


Page - 112


7.6.5.4 Service Flow Modification by the ASN 1 Figure 7-42 shows SF modification by the ASN. SF modification by the ASN may appear because of a trigger from 2 the P CC framework, a n u pdate of t he QoS pr ofile pr ovided by t he AAA or i f ASN c hanges t he state o f a pr e-3 provisioned SF between Active, Admitted or Provisioned. 4


DSC-Response

Path_Modification_Rsp


RR_Response(modify SF)

DSC-Request

Path_Modification_Req

RR_Request(modify SF)

DSC-Ack

Path_Modification_Ack


RR_Ack

5

Figure 7-42 - Service Flow Modification by ASN 6


Page - 113


7.6.5.5 Service Flow Creation by the MS 1 Figure 7-43 shows SF creation triggered by the MS. 2


DSA-Response

Path_Reg_Rsp


RR_Response

DSA-Request

Path_Reg_Req

RR_Request

DSA-Ack

Check against the QoS profile

Assign Resources

Path_Reg_Ack

RR_Ack

3

Figure 7-43 - Service Flow Creation by MS 4


Page - 114


7.6.5.6 Service Flow Deletion by the MS 1 Figure 7-44 shows SF deletion triggered by the MS. 2


DSD-Response

Path_DeReg_Rsp

RR_Response(delete SF)

DSD-Request

Path_DeReg_Req

RR_Request(delete SF)

Path_DeReg_Ack

RR_Ack

3

Figure 7-44 - Service Flow Deletion by MS 4


Page - 115


7.6.5.7 Service Flow Modification by the MS 1 Figure 7-45 show SF modification triggered by MS. For pre-provisioned SFs, the modification is limited to a state 2 change (change between Active, Admitted or Provisioned state), where no specific policy check is required. 3

In case of PCC, policy checks for dynamic SFs are done PCRF where the Anchor-SFA would contact the A-PCEF 4 to f orward th e r equest to th e P CRF. I f modification o f a S F i s n ot al lowed, t he A nchor S FA S HALL r eject t he 5 modification. 6

In no n-PCC cas e the Anchor S FA S HALL verify the validity of the modification against t he user’s Q oS profile 7 information ( except pr e-provisioned S F). F or pr e-provisioned S Fs, t he modification i s li mited to a s tate c hange 8 (change between Active, Admitted or Provisioned state), where no specific policy check is required. Policy checks 9 for dynamic SFs might be done with the help of the PCC framework where the Anchor-SFA would contact the A-10 PCEF to trigger the policy check in the PCRF. If modification of a SF is not allowed, the Anchor SFA SHALL 11 reject the modification. 12


DSC-Response

Path_Modification_Rsp


RR_Response(modify SF)

DSC-Request

Path_Modification_Req

RR_Request(modify SF)

DSC-Ack

Policy check against the QoS-profile received from

AAA as far as QoS resources shall be increased.

Assign Resources

Path_Modification_Ack

RR_Ack

13

Figure 7-45 - Service Flow Modification triggered by MS 14

7.6.5.8 Updating SFA Location 15 The anchor SFA remains co-located with the authenticator when the MS moves in the network. The serving SFA, 16 however, might change. T he anchor S FA SHALL keep t rack o f the c urrent serving S FA when network-triggered 17 service flows a re i mplemented. F or th is, the s erving SFA S HALL know t he i dentity o f t he a nchor S FA. T his 18 information can be achieved by the mobility procedures as the anchor SFA should be collocated with the AAA-19 client and SHALL be addressed by the Authenticator ID. The serving SFA should be collocated with the FA / AR 20 and SHALL be addressed by the Anchor GW ID as the Serving-SFA triggers the DP-handling on the Anchor-DP 21 function. At any point of time there is only a s ingle active instance of Anchor SFA and a s ingle active instance of 22 Serving SFA that may be co-located. 23


Page - 116


7.6.6 IP Differentiated Services 1 Differentiated services (diffserv) is an IP layer QoS mechanism, whereby IP packets are marked with diffserv code 2 points at the network point of entry and network elements enforce relative priority of packets based on their code 3 points. T he d iffserv methodology al lows n etwork r esources t o b e r eserved f or cl asses o f t raffic, r ather t han for 4 individual flows, as defined in [18]. 5

In the context of the WiMAX® air link, IP diffserv mechanism can be used to enforce priorities for packets within a 6 service flow, or to establish service flows based on diffserv classes for a g iven subscriber. As an example, a s ingle 7 pre-provisioned service flow for a subscriber can be used to carry multiple types of traffic, with relative precedence 8 established b ased o n diffserv code p oints. On t he other hand, service flows MAY be established dynamically to 9 carry different diffserv traffic classes. An example of this is the establishment of a UGS service flow dynamically to 10 carry a voice call, where the voice traffic is marked with diffserv EF class (described in [20]). 11

In t he first cas e ab ove, the d iffserv code points ar e used t o p rioritize an d schedule packet transmission within a 12 service flow. The manner in which this is done is a matter of local implementation in the BS and the SS, subject to 13 the prioritization rules of diffserv. In the second case, the diffserv code point is used to classify packets onto separate 14 service flows. This scenario occurs when packets entering the BS or the MS are already marked with diffserv code 15 points by an application or some prior network entity. 16

7.6.7 QoS Profile in the MS 17 In case of MS initiated SF creation, if the MS has information about supported and authorized QoS of the subscriber, 18 the MS can use it to create proper SF requests. 19

MS M AY be c onfigured with Q oS pr ofile. P er ope rator pol icy, Q oS pr ofile MAY be c onfigured i n the M S 20 whenever t he subscriber Q oS P rofile i s cr eated o r ch anges. I t i s implementation s pecific h ow t he M S u ses Q oS 21 profile in determining QoS attributes for formulating SF creation or modification requests. 22

7.6.8 Priorization for Ethernet Services 23 The user_priority field in the VLAN Tag can be used to mark the particular QoS class o f E thernet frames in the 24 wired part of the WiMAX network. User_priority, if present is usually set at the entry to the network and MAY be 25 used by network elements along the path for control of the treatment of the frames in the forwarding process. 26

The Layer 2 Forwarding (L2FW) function in the ASN-GW SHALL support the assignment of the priority bits in the 27 VLAN tag in upstream and downstream direction for each service flow dependent of the QoS profile provisioned by 28 the AAA server. The assignment of the priority bits SHALL follow one of three ways listed below: 29

• Forward the frame without modification of the priority bits 30

• Set the priority bits to a value provided by the AAA server as part of the SF specification 31

• Restrict the usage of a higher priority than signaled by the AAA server as part of the SF specification. 32

o Frames with p riorities h igher th an a llowed S HALL e ither b e r emarked to th e h ighest a llowed 33 value or be dropped. 34

If a ssignment o f t he p riority_field i n t he V LAN tag is enforced for a particular service f low, the L2FW function 35 SHALL insert VLAN tags with VLAN ID and priority field set to the specified values into Ethernet frames without 36 VLAN tags belonging to the service flow. 37

7.6.9 VLAN Tag Processing for Ethernet Services 38 VLAN-IDs are used in many different ways for segregating traffic of Ethernet services in the access network. The 39 L2FW f unction in t he A SN-GW S HALL support t he flexible us e of the V LAN-IDs b y pr oviding t he following 40 capabilities for each of the service flows: 41

The configuration information of the VLAN tag processing SHALL be provided by the AAA server as part of the 42 SF specification. 43

In downstream direction towards the MS: 44

• The L2FW SHALL be able to remove S-VLAN tags or C-VLAN tags if present. The VLAN tags SHALL 45 be removed after making use of the VLAN tag for classification purposes. 46


Page - 117


In upstream direction from the MS: 1

• The L 2FW S HALL be a ble t o a dd S -VLAN t ags to E thernet f rames c ontaining a C-VLAN t ag. T he 2 inserted S -VIDs may b e ei ther s et t o a f ixed v alue o r as signed d epending o f t he C-VID acco rding t o a 3 mapping table provided by the AAA server as part of the SF specification. The priority bits SHALL be 4 either set to a f ixed value provided by the AAA server as part of the SF specification or copied from the 5 priority bits in the C-VLAN tag. 6

• The L2FW SHALL b e able to i nsert V LAN tags with a n assigned C-VID into E thernet f rames without 7 VLAN tagging. The C-VID value and the priority bits are provided as part of the SF specification by the 8 AAA server. 9

Service flows belonging to a MS SHALL inherit the VLAN tag processing behavior of the ISF when nothing is 10 specified for the particular service flow but a specification is provided for the ISF. 11

For local configuration a string MAY be provided for local use together with the configuration information of the 12 VLANTagProcessing. 13

Note: The string provided together with the configuration information of the VLANTagProcessing may be used e.g. 14 for configuration of the R3 data path for other transport protocols like MPLS or IEEE802.1ah (MAC-in-MAC) in 15 the case of Simple Ethernet. 16

Note: VLANTagProcessing configuration is part of the packet flow descriptor, which can be pre-configured locally. 17 The means to provide the local configuration data is out of scope of this specification.. 18

7.7 ASN Anchored Mobility Management 19

7.7.1 Scope 20 ASN Anchored Mobility Management is defined as mobility of an MS not involving a CoA update (i.e., a MIP re-21 registration). P rocedures described for ASN Anchored Mobility Management a lso apply for mobility in networks 22 not b ased o n MIP. T here M AY b e s cenarios i nvolving "ASN Anchored M obility M anagement", f ollowed b y 23 subsequent CoA update a nd CSN Anchored M obility Management. In this c ase the initial mobility management 24 procedures u p t o t he C oA u pdate t rigger ar e d escribed here, while t he p rocedures s tarting with CoA u pdate 25 triggering are in the scope of Section 7.8. 26

7.7.2 Functional Requirements for ASN Anchored Mobility Management 27 The functional requirements for ASN Anchored Mobility Management are: 28

a) The architecture SHALL accommodate three scenarios of operation (as described in [79]): 29

o Nomadicity (and fixed access) 30

o Portability and with Simple Mobility 31

o Full Mobility 32

b) The architecture SHALL consider: 33

o Minimizing or eliminating packet loss 34

o Minimizing handoff latency 35

o Maintaining packet ordering 36

c) The ar chitecture S HALL co mply with t he s ecurity a nd t rust ar chitecture d efined i n t he I EEE 8 02.16 37 specification and IETF EAP RFCs. 38

d) The architecture SHALL support private addresses allocated by the Home NSP or the Visited NSP, as well 39 as NAP sharing. 40

e) The ar chitecture S HOULD support Macro-Diversity Ha ndoff ( MDHO) and F ast B ase Station S election 41 (FBSS). 42

f) The architecture SHOULD support MS in various states - Active, Idle, and Sleep. 43


Page - 118


g) The number of roundtrips of signaling between BS and Intra-ASN mobility anchor point to execute a HO 1 SHALL be minimized. 2

h) The HO control primitives and Data Path enforcement control primitives SHALL be independent of each 3 other such that it allows separation of HO control and Data Path enforcement control. 4

i) The Data Path enforcement mechanism SHOULD support and be compatible with the WiMAX Forum® 5 QoS Architecture. 6

7.7.2.1 ASN Anchored Mobility Management Consideration 7 This section mentions ASN Anchored Mobility Management: 8

a) It SHOULD support multiple deployment scenarios. 9

b) It SHOULD be agnostic to the ASN Decomposition, and SHOULD work with any defined form of ASN 10 construction and profiles. 11

c) It SHOULD accommodate HO procedures for Data Path anchoring as well as procedures for re-anchoring. 12

d) It SHOULD acco mmodate signaling and data t ransmission protocols within an ASN or ASNs which are 13 within a NAP administrative domain. 14

e) The protocol SHALL accommodate Data Path type with per Service-Flow granularity. 15

f) It SHOULD be independent of RRM procedures. 16

7.7.2.2 ASN Anchored Mobility Management Functional Decomposition 17 The ASN Anchored Mobility Management SHALL be defined by the following functions: 18

• Data Path (Bearer) Function: Manages the data path setup and includes procedures for data packet 19 transmission between two functional entities. 20

• Handoff Function: Controls overall HO decision operation and signaling procedures related to HO. 21

• Context Function: Addresses the exchanges required in order to setup any state or retrieve any state in 22 network elements. 23

Each of these functions is viewed as a peer-to-peer interaction corresponding to the function. 24


Page - 119


7.7.2.2.1 Generic ASN Anchored Mobility Management Functional Reference 1

ContextServer

Anchor DPFunction

Relay HOFunction

ContextRelay

Relay DPFunction

Relay DPFunction

ContextRelay

ContextClient

Target DPFunction

Target HOFunction

Serving HOFunction

Serving DPFunction

ContextClient

2

Figure 7-46 - Overall Reference for ASN Mobility Functions 3

Figure 7-46 depicts the relationship between the functional entities. 4

7.7.2.2.2 Data Path Function 5 The Data Path Function manages the setup of the bearer plane between two peers. This MAY include setup of any 6 tunnels and/or additional functionality that MAY be required for handling the bearer plane. The Data Path function 7 is used t o setup t he b earer p lane b etween B ase-Stations o r b etween o ther e ntities s uch a s G ateways o r b etween 8 gateways and base-stations. Any additional requirements such as support of multicast or broadcast are also handled 9 by this function. Data Path Function shall support the use of packet sequence number. The Data Path Function i s 10 also used to optionally ensure a low latency connection during handovers. 11

Each Data Path function is responsible for instantiating and managing data bearer between it and another Data Path 12 function a nd f or s electing t he p ayload t raversing t he es tablished d ata b earer. T here ar e t wo types o f D ata P ath 13 Functions: 14

Type 1: IP or Ethernet packet forwarding with layer-2 or layer-3 transport 15

For Type 1, data path bearer is typically a generic layer 3 tunnels (e.g. IP-in-IP or GRE) a layer-2 network such 16 as E thernet o r MP LS. T he p ayload i s an IP d atagram or an E thernet p acket. Additional s emantics c an b e 17 applied t o t he t ransport h eader a nd pa yload t o h andle scenarios such a s header c ompression, s equenced 18 delivery. The data bearer can be routed or bridged. 19

Type 2: forwarding with Layer-2 or layer-3 transport 20

For Type 2, data path bearer is also typically a generic layer 3 tunnels (e.g. IP-in-IP or GRE) a layer-2 network 21 such as Ethernet or MPLS. The payload is a Layer-2 data packet which is defined as an 802.16e MAC Service 22 Data U nit ( SDU) o r p art o f it a ppended with a dditional i nformation s uch a s CID o f Target B S, A utomatic 23 Retransmission Request (ARQ) parameters, etc. In Type 2, layer-2 session state (e.g., ARQ state) is anchored in 24 the Anchor Data Path Function. 25

The Data Path Function can be further classified by its roles in handover and initial entry operation as follows: 26


Page - 120


• Anchor DP Function: The DP (Data Path) Function at one end of the data path, which anchors the data 1 path associated with the MS across handovers. This Function SHALL forward the received data packet 2 toward the Serving DP function using either Type 1 or Type 2 Data Path. This Function MAY buffer the 3 data packets from the network and maintain some state information related to bearer for MS during 4 handovers. 5

• Serving DP Function: The DP Function at other end of a data path,, at the moment, has the association 6 with the Serving PHY/MAC function and takes charge of transmission of all messages associated with the 7 corresponding MS. This DP Function, associated with a Serving BS, communicates with the Anchor DP 8 Function through Type-1 or Type-2 Data Path, to forward/receive MS data packets. 9

• Target (New Serving) DP Function: The DP Function which has been selected as the target for the 10 handover. This DP Function, associated with a Target BS, communicates with the Anchor DP Function to 11 prepare a Data Path to replace the current path after the completion of the handover. Upon successful 12 handoff it will assume the role of Serving DP. 13

• Relaying DP Function: The DP Function which mediates information delivery between Serving, Target 14 and Anchor DP Functions. 15

7.7.2.2.2.1 Data Path Considerations 16 The uplink and downlink subscriber f lows between Data Path Functions SHALL be forwarded using per Service-17 Flow granularity. 18

As shown in Figure 7-47, there is only one level of aggregation that can be used to transfer subscriber flows over a 19 Data Path. 20

• Per Service Flow per subscriber i.e. finest classification granularity. 21 Each individual Service Flow of a subscriber is given a specific forwarding treatment across the ASN. 22

A Data Path is identified via the classification operation based on a set of classification criteria such as MS MAC 23 address. 24

The flow classification of each Type of Data Path Function MAY use different parameters as the classifier. That is, 25 for example, Type-2 Data Path Function SHALL use the information included in the layer-2 packets such as MS 26 MAC address, CID, etc. 27

The pr otocols c onsidered i n t he f ollowing di scussion a re G RE, MPLS a nd 802. 1Q VLANs a re e xamples of 28 technologies that can be used to forward subscriber f lows across ASN. These technologies provide for a level of 29 keying or tagging between the two end-points. Such a t ag or key MAY be used in a cl assification decision by the 30 Data Path Function. 31

The protocol that SHALL be used on R4 and R6 is GRE. 32


Page - 121


Per application flow per subscriber forwarding



1

Figure 7-47 - Data Path Granularity 2


Page - 122


7.7.2.2.2.2 Type-1 Bearer Operation 1 Typically, a Type-1 Bearer is used to send IP or Ethernet packets tunneled or tagged using GRE, MPLS or 802.1Q 2 etc. between the data path functional peers. In order to satisfy several requirements such as overlapping addresses as 3 well as layer-2 transparency, a protocol which provides a level of tagging MAY be desirable for use with Type-1 4 Bearer. Such a tagging helps in identification of the specific QoS flows associated with the MS. 5

Type-1 Bearers are used to deliver the payload associated with a user to the respective data path peer function. A 6 Type-1 Bearer can be created per MS QoS Flow (SFID). When a Type-1 bearer is created per MS QoS Flow, a 7 directional key or tag MAY be associated with the bearer. 8

When a k ey or tag is used, the bearer is classified to the appropriate MS QoS Flow (SFID) based on the classifier 9 programmed for the traffic addressed to the specific MS. The traffic received from the MS MAY be mapped on to 10 the data path based on the CID. 11

GRE shall be the tunneling protocol. ‘pure’ IP packet will be transported by a per-flow GRE tunnel. 12

Figure 7-41 below shows an example of the classification operations for Type-1 Bearer. 13

Classifiers

Identification of specific key and datapath tunnel

Transmit packet with correct Data Path Tagtowards MS

Classify based on CID

Transmit packet with correct Data Path Tagfrom MS

Identification of specific key and datapath tunnel

Data Packet (Towards MS) Data Packet (From MS)

14

Figure 7-48 - Optional Classification Operations of Type 1 Bearer 15


Page - 123


7.7.2.2.2.3 Type 2 Bearer Operation 1 Type 2 Data Path is optional. 2

7.7.2.2.2.3.1 Data Anchoring: Data Packet or ARQ Block 3 When e mploying T ype-2 Data P ath for Intra- and I nter-ASN mobility s upport, layer-3 data communication path 4 from the core network to the Anchor Data Path SHALL NOT be changed by HO and remains the same as what is 5 before the HO. With the T ype-2 Data Path Function, s witching o f path for l ayer-3 data co mmunication MAY be 6 deferred until a session relocation request from a HO Function becomes outstanding. 7

Figure 7-49 below shows a typical mobility model that employs Type-2 Data Path. 8

IP Cloud

Anchor DP Fn

- L2 Session Anchoring- L2 Data Anchoring- Packet Buffering

Serving DP Fn

- Air Interface to MS- MAC PDU generation- Scheduling

Target DP Fn

- Network Re-entryProcessing- Update of Air Interface

MS MS MS

ASN 1

Type-2 Data Path(The Path carries Layer-2

Data Packets)

L3(IP) Data Path

9

Figure 7-49 - Layer-2 Data Anchoring with Type-2 DP Function 10

In a mobility model that employs Type-2 Data Path Function, the Anchor Data Path Function MAY be located in the 11 different entity from what has the Foreign Agent function. And, in this model, R3 mobility event MAY be deferred 12 until the Anchor Handover Function triggers the R3 MM. 13

In Type-2, the Anchor Data Path Function SHALL anchor active Layer-2 sessions including ARQ States, and data 14 paths used to transmit user IP packets to/from core network. 15

In T ype-2, the Anchor Data Path Function SHALL generate Layer 2 Data Packets7

7 Here, t he Layer-2 p acket d oes not mean MAC Protocol Data Unit (PDU). It is rather MAC S ervice D ata U nit (SDU) appended with additional information such as CID of Target BS, ARQ parameters, etc.

from the received layer 3 IP 16 packets, a nd t hen e ncapsulate t hem into t he t unnel p ackets t o forward t hem toward t he ap propriate d estination 17 Functional Entity. 18


Page - 124


In Type-2, the Serving Data Path Function, residing in the Functional Entity that has 802.16 physical associations 1 with MS now, SHALL take charge of transmissions of all MAC messages to MS. 2

If MS moves to another cel l and a h andover is desired, the Target Data Path Function, residing in the Functional 3 Entity th at is d etermined a s t he ta rget for th e handover, S HALL perform ba ckbone c ommunication with Anchor 4 Data Path Function to prepare a Type-2 Data Path to serve the pending MS handover. 5

7.7.2.2.2.3.2 Bearer Operation 6 In Type-2, bearer paths SHALL be used to deliver Layer-2 Data Packets between the Anchor Data Path Function 7 and the Serving Data Path Function. A Layer-2 data packet is defined as an 802.16e MAC SDU or part of it which is 8 appended with additional information such as CID of Target BS, ARQ parameters, etc. 9

Figure 7-48 below illustrates the overall data transmission process over a bearer of Type-2 Data Path Function. 10

Classification $Mapping to SFID/CID

Applying appropriatePHS process

Atta

chin

g ad

ditio

nal

cont

rol i

nfor

mat

ion

En(

De)

caps

ulat

ion

for

tunn

el tr

ansp

ort

De(E

n)capsulation fortunnel transport

De-attaching additionalcontrol inform

ation

Type-2Data Path

Tunneled Layer-2Data Packets

Serving DP FnAnchor DP Fn

Data Packet

11

Figure 7-50 - Data Transmission over Type-2 Bearer 12

When a n IP packet a rrives a t the Anchor Data P ath F unction through a data path, it SHALL be c lassified by t he 13 Anchor Data Path Function and mapped to an appropriate IEEE 802.16 Service Flow and SFID. 14

Then the Anchor Data Path Function MAY apply an appropriate Packet Header Suppression rule per SFID to the 15 packet to make a MAC CS PDU (i.e., MAC SDU), segment the MAC SDU into an appropriate size, if required, and 16 attaches additional control information such as CID, ARQ parameters, etc. to the MAC SDU. 17

The Anchor Data Path Function then encapsulates the output into IP tunnel packet to transmit to Serving Data Path 18 Function through a Type-2 Data Path. 19

The Serving Data Path Function SHALL de-encapsulate the Layer-2 Data Packets and control information, which 20 was attached by the Anchor Data Path Function, from the packet received through the data path bearer. 21

7.7.2.2.2.3.3 ARQ State Anchoring 22 In Type-2 Data Path Function, ARQ state is anchored at the Anchor Data Path Function. In this case, ARQ states, as 23 well as the data packets themselves, SHALL be retained at the Anchor Data Path Function in spite of HOs, and data 24 packets need not be retransmitted over the radio link to recover the state mismatch between MS and network or the 25 state reset are caused by the handover process. 26


Page - 125


When the Anchor Data Path Function receives an IP packet for an ARQ-enabled connection from the network, it 1 converts the IP packet into Layer-2 Data Packet(s) or packets, as specified in Section 7.7.2.2.2.3.2. If it converts the 2 IP packet into a set of Layer-2 Data Packets, the size of each converted Layer-2 Data Packet SHALL be a multiple 3 of ARQ block size and the content of each Layer-2 Data Packets SHALL be extracted around the ARQ block size 4 boundaries. That is, only a datagram which consists of n tuples of ARQ block SHALL be transmitted through the 5 Type 2 Data Path. For the ARQ-enabled connection, the Anchor Data Path Function SHALL attach ARQ control 6 information, such as Retransmission State, Starting ARQ BSN, etc., to Layer-2 Data Packets. After all Layer-2 Data 7 Packets which are produced from the same MAC SDU, the Anchor Data Path Function SHALL store the MAC SDU 8 and the related ARQ control information locally for possible retransmission request from MS. 9

The attached information SHALL be used by the Serving D ata P ath Function t o divide a received Layer-2 D ata 10 Packet into a set of ARQ Blocks. That is, the Serving Data Path Function divides the received packet into ARQ 11 blocks with the pre-specified ARQ block size, and then assigns an ARQ BSN to each block, with starting from the 12 Starting_ARQ_BSN received from the Anchor Data Path Function through Type-2 Data Path and increasing one for 13 each block. 14

When an ARQ block(s) is requested to be retransmitted by MS or when an ARQ Ack has not been received for an 15 ARQ block(s) within the pre-specified ARQ timeout, then the Anchor Data Path Function SHALL refer to the ARQ 16 state of the c onnection t o support r etransmission a ccording t o t he ARQ BSN information a nd update t he ARQ 17 retransmission state value. The remaining packet transmission process in the Serving Data Path Function will be the 18 same excepting that it is treated as retransmission. 19

7.7.2.2.3 Handoff Function 20 The following types of handovers are supported by the handoff function: 21

• Mobile initiated handovers at a given serving Base-Station. 22

• Network initiated handovers. 23

• FBSS and MDHO (possibility to support MDHO SHOULD be further discussed). 24

The Handoff Function can be further classified by its roles in handover operation as follows: 25

• Serving HO Function: The Handover function which controls overall HO decision operation and signaling 26 procedures related to HO. It signals the Target HO Function, via zero or more Relaying HO Functions, to 27 prepare for handover, and sends the result to MS. 28

• Relaying HO Function: This Function relays HO related control messages between Serving and Target 29 HO Functions. A Relay HO Function MAY modify the content of HO messages and impact HO decisions. 30

• Target HO Function: The Handover function which has been selected as the target for the handover, or a 31 potential target for the handover. 32

7.7.2.2.4 Context Function 33 Due to intra-NAP mobility, there is an MS related context in the network and network related context in MS that 34 need to be either transferred and/or updated. Specifically, 35

• MS specific context in the Context Function associated with the Serving/Anchor Handoff function needs to 36 be updated. 37

• MS specific context in the Context Function associated with the Serving Handoff function that needs to be 38 transferred to the Context Function associated with the Target Handoff function. This will also require 39 some of Network specific context in MS to be updated. 40

This specification defines primitives between peer Context Functions that are used to transfer MS specific context 41 between a Context Function acting as Context-Server and a Context function acting as Context-Client. 42

The information transfer regarding a specific MS can be triggered in the following scenarios (not exhaustive). 43

• To populate the context e.g., security context corresponding to a MS at a target Base-Station. 44

• To inform the network regarding the idle mode behaviors of the MS. 45


Page - 126


• To inform the network of initial network entry of a specific MS. 1

The Context Function can be further classified as: 2

• Context-Server: The Context function is the repository of the most updated session context information 3 for MS. 4

• Context-Client: The Context function which is associated with the functional entity that has the 802.16 5 physical link. It retrieves session context information stored at the Context Server during the handover 6 procedure. 7

• Relaying Context Function: The Context Function which relays information delivery between the Context 8 Server and the Context Client. 9

7.7.2.2.5 SFID and CID Management 10 Per IEEE Std 802.16, Service Flow ID (SFID) does not change upon HO across BSs belonging to a single NAP, 11 while Connection ID (CID) is defined as temporary in a particular cell coverage area. SFID SHALL be set just once 12 when a layer 2 service flow is originally established, and SHALL NOT be modified by HOs. On the contrary, CID 13 SHALL be refreshed whenever MS moves into a n ew cell. SFID identifies a p articular Layer 2 session while CID 14 specifies a particular logical radio link. 15

SFID SHALL be assigned when a new service flow is set up and SHALL be maintained as the same value at the 16 Anchor D ata P ath F unction i n s pite o f H Os. I n normal s ituation, CID S HALL b e a ssigned b y t he S erving BS. 17 However, in handover situation, new CID SHALL be allocated by the Target BS during HO procedures. 18

In Type 2 Data Path Function, the new CID SHALL be transmitted from the Target Handoff Function to the Serving 19 Handoff Function through the backbone communication and SHALL be mapped to the corresponding SFID at the 20 Anchor Data Path Function to relocate the Data Path. The CID SHALL never be used to identify a session at the 21 Anchor Data Path Function. It is only used as tag information for Layer-2 Data Packet (tunnel) transmission by the 22 Anchor D ata P ath F unction. That i s, when a p acket i s t ransmitted from the Anchor D ata P ath F unction t o t he 23 Serving D ata Path F unction through Type-2 D ata P ath, th e S FID for th e p acket will b e tr anslated i nto t he 24 corresponding CID at the Serving Data Path Function and be attached as a tag to the packet. Therefore, a connection 25 is identified by SFID in the Anchor Data Path Function and by CID in the Serving Data Path Function. 26

7.7.2.2.6 Data Integrity Consideration During HO 27 Different class of services imposes different requirements in the quality of the traffic delivered to the MS, which is 28 measured mainly on the basis of data integrity, latency and jitter. The impact of HO in any of these parameters shall 29 be m inimized. M ore co ncretely, maintaining d ata i ntegrity d uring HO i mplies t hat the r ate o f p acket loss, 30 duplication or reordering will not be substantially increased as a result of HO, while, at the same time, impact on 31 datapath setup latency /jitter shall be kept to a minimum. 32

From QoS point of view, there are 2 types of HO: controlled and uncontrolled. A controlled HO is the one that 33 respects the following conditions: 34

• If the HO is MS initiated, the MS shall communicate to the BS a list of potential targets via msg #1 35 (MOB_MSHO-REQ). 36

• The network SHALL perform target selection based on the list of potential targets provided by the MS 37 (when MS initiated HO). The anchor DPF or serving DPF may start bi-casting or multicasting to all 38 potential targets. 39

• The network SHALL communicate to the MS the list of available targets for HO (MOB_BSHO-RSP or 40 MOB_BSHO-REQ). If the list is void, the network refuses to accept MS HO. 41

• The targets provided by the network to the MS should be a subset of the ones requested by the MS or 42 reported by the MS via MOB_SCN-REP. 43

• The MS SHALL move to one of the targets provided by the network or rejects the HO. 44

• The MS shall perform HO or reject by sending MOB_HO-IND. 45


Page - 127


If any of the above conditions is not respected, the HO is considered as uncontrolled or un-predictive, and QoS is 1 not guaranteed. 2

If the MS leaves the serving BS before receiving MOB-BSHO_RSP but it succeeds to at least send MOB-BSHO-3 IND with an indication of the target BS, this is considered uncontrolled HO. In the worst case, the MS may suddenly 4 connect in the target BS without any indication given to the target BS: this is considered as un-predictive HO. 5

Several Data i ntegrity mechanisms ar e p rovided, an d the selection o f D ata integrity mechanism i s co nfiguration 6 issue. T hese mechanisms ca n b e cl assified i n 2 main groups: d atapath s etup a nd datapath s ynchronization 7 alternatives. 8

7.7.2.2.6.1 Data Path Setup Mechanism (Buffer Transferring vs. Bi/Multicasting) 9 Datapath setup mechanisms refer mainly to R6 datapath, but when anchoring (i.e., R4 forwarding or R8 forwarding) 10 the same concepts are applicable. Data integrity mechanisms available for guaranteeing data integrity: 11

• Buffering: Traffic of the services for which data integrity is required is buffered in the datapath Originator 12 or in the Terminator. For one direction traffic, DP Originator is the DP function that sends data to another 13 DP functions, and DP terminator is the DP function that receives data from another DP functions and 14 delivers data through the air-interface. This buffering might be done only during the HO or for simplicity it 15 might be done within the lifetime of the session. The buffering can be conducted in Datapath Originator or 16 terminator. And the buffering in this section is referred to the buffering mechanisms during HO, the 17 buffering point MAY change during HO base on data integrity mechanism selection. 18

• Bi/Multi-casting: This technique consists on multicasting downstream traffic at the Originator endpoint of 19 the datapath. Bicasting is a particular case: traffic is bicasted to the serving element and to only 1 target. 20 There’s no such concept as upstream multicast in the context of data Integrity. 21

These t wo mechanisms ar e n ot mutually e xclusive, i n fact b i-casting o ffers a b etter r esult when co mbined with 22 buffering. 23

While multicasting requires setting up multiple data paths, this is not the case for buffering. Buffering is considered 24 as a d atapath setup mechanism since t he s equencing o f the d atapath switch will b e determined b y where t he 25 buffering is done. 26

7.7.2.2.6.2 Data Delivery Synchronization Mechanism 27 In order to synchronize guarantee the data delivery in different data functions which buffered the different data paths 28 (serving and target) used to deliver the data during HO, certain synchronization methods can be used and the data 29 need to be synchronized. This synchronization can be achieved in 3 different ways: 30

a) Using Sequence number: A sequence number is attached to each SDU in the ASN datapath. This sequence 31 number SHALL be increased by 1 every time a SDU is forwarded in the datapath. There are two options to 32 obtain S N o f last tr ansmitted S DU b y s erving d atapath function d uring handover. O ne i s r eported b y 33 serving datapath function, and the other i s through SDU SN report by MS as described in IEEE802.16e-34 2005. The used of the SNs is different depending on the buffering mechanism used for maintain the data 35 integrity, example: 36

b) Buffering in the datapath Originator: For downlink traffic, the serving datapath function MAY report to the 37 Originator an acknowledgement o f the S DUs delivered to the MS while the HO s tart. So after HO, the 38 target D P f unction b ecomes Terminator an d co ntinue r eceive d ata f rom t he S DU next t o t he l ast o ne 39 acknowledged from originator. See section 7.7.6.1.1 for details. 40

These acknowledgements are not meant to guarantee reliable delivery in the ASN at all times since there’s 41 no retransmission). 42

c) Buffering in the datapath Terminator: if multi / bi-casting is used, the serving terminator SHALL report 43 to the originator the SN of the first SDU need to multicast to the target(s) DP terminators. When actual HO 44 is started, the target terminator start sending the SDU next to the last one acknowledged SDU to MS. See 45 section 7.7.6.1.2 for details. 46


Page - 128


If no multicasting is used, After HO, the DP terminating point is changed from serving to the target DP. 1 The SN of last Ack SDU SN is reported to the target terminator. The datapath Originator MAY report to 2 the Serving Terminator the SN of the last SDU for the Serving Terminator to validate that there’s no packet 3 in flight in the datapath. The example procedure is demonstrated in section 7.7.6.1.3. 4

Data retrieving: Without creating SN for each SDU, the Anchor DPF copy/buffer the data during HO preparation, 5 when a f inal ta rget BS is identified through HO-IND, the serving BS is a sked to push back a ll of its un-sent/un-6 acked packets to anchor / ta rget DF. See section 7 .7.6.1.4 for details. For sequential delivery, the method can be 7 used with sequence number enable. 8

Ack window with Sequence number disable: Data Storage buffers in Anchor DP are released by full or partial ACKs 9 from serving BS without sequence number needed. See section 7.7.6.1.5 for details. The method can be used with 10 sequence number enable also. 11

7.7.2.2.6.3 ARQ Synchronization 12 There are two types Data Path in ASN and how to maintain ARQ state synchronization differs between them. 13

In Type-1 Data Path, ARQ states SHOULD be synchronized. The details are in 7.7.2.2.6.3.1 and 7.7.2.2.6.3.2. 14

In Type-2 Data Path, ARQ states MAY also be anchored at the ARQ Anchoring which resides in Anchor Data Path 15 Function. The detail is in 7.7.2.2.2.3.3. 16

7.7.2.2.6.3.1 ARQ Synchronization for Downlink 17 For ARQ enable traffic, IEEE Std 802.16e MAC divides the SDUs onto logical parts called ARQ Blocks. All Blocks 18 are of equal size except from the last one in the SDU (the Block Size is a per Connection parameter). Each Block is 19 assigned a sequence number called Block Sequence Number – BSN. The IEEE Std 802.16e MAC ARQ works with 20 BSNs. 21

A t ypical s ituation with th e t ransmission b uffer in th e S erving M AC F unction, which M AY o ccur p rior to M S 22 leaving, is shown on the Figure 7-51. The transmission buffer in MAC Function might be represented as sequence of 23 Blocks labeled with BSNs. On the other hand each BSN belongs to the corresponding SDU labeled with SDU SN. 24 The situation on the Figure 7-51 appears as follows: 25

• All the Blocks belonging to all the SDUs with SNs lower than Y have been transmitted and acknowledged. 26

• The first SDU with unacknowledged Blocks is labeled with SN = Y and the Block which corresponds to 27 the beginning of that SDU is labeled with BSN = B. And, the Block with BSN = B has been transmitted 28 and acknowledged. 29

• The Blocks labeled with BSN = B+1 and BSN = B+2 also belong to the SDU labeled with SN = Y. The 30 Block with BSN = B+2 has been transmitted and acknowledged while the Block with BSN = B+1 has been 31 transmitted but not acknowledged. 32

• The Blocks from BSN = B+3 to BSN = B+6 belong to the SDU with SN = Y+1. The Block with BSN = 33 B+3 has been transmitted but not acknowledged. The Block with BSN = B+4 has been transmitted but and 34 acknowledged. The Blocks with BSN = B+5 and BSN = B+6 have not been transmitted yet. 35

• No Block belonging to any SDU with SNs higher than Y+1 has been transmitted. 36

Thus in order to synchronize ARQ States between the Serving and Target MAC Functions the former SHOULD 37 share with th e la ter t he i nformation about t he ARQ State and downlink S DU / ARQ Blocks buffers ( per Service 38 Flow). 39

The specific details of how the whole ARQ state is synchronized can be found in stage 3. 40


Page - 129


All Blocks of all SDUs with SN greater than Y+1 have not been sent

B+6

B+5

B+4

B+2

B

B+3

B+1

Blocks That Have Not Been Sent(BSNs = B+5, B+6)

Sent But Not Acknowledged(BSNs = B+1, B+3)

Sent And Acknowledged Blocks(BSNs = B, B+2, B+4)

All Blocks of all SDUs with SN lower than Y have been sent andacknowledged

SDU SN= Y

SDU SN= Y+1

1

Figure 7-51 - Transmission Buffer in the Serving BS upon MS Leaving 2

7.7.2.2.6.3.2 ARQ Synchronization for Uplink 3 A typical situation with the reception buffer in the Serving MAC Function, which MAY occur prior to MS leaving, 4 is shown on the Figure 7-52. The transmission buffer in MAC Function might be represented as sequence of Blocks 5 labeled with BSNs. On the other hand each BSN belongs to the co rresponding SDU labeled with SDU SN. The 6 situation on the Figure 7-52 appears as follows: 7

• All the Blocks belonging to all the SDUs with SNs lower than Z have been received and acknowledged. 8

• The first SDU with unacknowledged Blocks is labeled with SN = Z and the Block which corresponds to the 9 beginning of that SDU is labeled with BSN = b. And, the Block with BSN = B has been transmitted and 10 acknowledged. 11

• The Blocks labeled with BSN = b+1 and BSN = b+2 also belong to the SDU labeled with SN = Z. The 12 Block with BSN = b+1 has been received and acknowledged while the Block with BSN = b+2 has been 13 received but not acknowledged. 14

• The Blocks from BSN = b+3 to BSN = B+6 belong to the SDU with SN = Z+1. The Block with BSN = b+3 15 and the Block with BSN = b+4 have been received but not acknowledged. The Block with BSN = b+5 and 16 the Block with BSN = b+6 have not been received yet. 17

• No Block belonging to any SDU with SNs higher than Z+1 has been received. 18

Thus in order to synchronize ARQ States between the Serving and Target MAC Function the former share with the 19 later the information about the ARQ State and uplink SDU /ARQ Blocks buffers (per Service Flow). 20

When the T arget B S r eceives t he s ynchronization information d iscussed ab ove i t ca n p roceed i n o ne o f t hree 21 possible ways discussed in 7.7.2.2.6.3.2.1, 7.7.2.2.6.3.2.2 and 7.7.2.2.6.3.2.3. 22


Page - 130


No Block of any SDU with SN greater than Z+1 has not been received

Block That Have Not Been Received(BSNs = b+5, b+6)

Received But Not AcknowledgedBlocks (BSNs = b+1, b+3)

Received And Acknowledged BlocksBlocks (BSNs = b, b+2, b+4)

All Blocks of all SDUs with SN lower than Z have been received and acknowledged

b

b+2

b+4

b+1

b+3

b+5

b+6

SDU SN= Z

SDU SN= Z+1

1

Figure 7-52 - Reception Buffer in the Serving BS upon MS Leaving 2

7.7.2.2.6.3.2.1 MS Resending Incomplete SDUs 3 This approach suggests that the Target MAC Function instructs the MS to reset its ARQ state and start transmitting 4 again from the first Block of the first SDU with unacknowledged Blocks. In the example shown on the Figure 7-52 5 the MS will have to resend Blocks starting with the Block with BSN=b. 6

This approach allows simple implementation but introduces some overhead over the air. 7

7.7.2.2.6.3.2.2 Re-Assembly in the Anchor DP Function 8 This approach suggests that the Target DP Function MAY send fragments of the SDUs to the Anchor DP Function 9 thus delegating reassembly of the SDUs to the latter. 10

This approach is more complex for implementation, but allows lower overhead over the air. 11

7.7.2.2.6.3.2.3 Re-Assembly in the MAC Data Path Function 12 In this approach, only complete SDUs SHALL travel between the MAC and FA function. Upon HO, the source 13 MAC function SHALL transfer any received blocks to the target MAC function along with the acknowledged/un-14 acknowledged status. The target MAC function SHALL have the responsibility of completing acknowledgement of 15


Page - 131


non-acknowledged blocks as well as re-assembling received blocks into complete SDUs before transmitting uplink 1 to the FA function. 2

7.7.3 HO Function 3

7.7.3.1 HO Function Network Transaction 4 HO Function Transaction is shown in Figure 7-53. 5

HO Function(Serving)

HO Function(Relaying)

HO Function(Relaying)

HO Function(Target1)

HO Function(Target2)

HO_ReqHO_Req

HO_RspHO_Rsp

HO_RspHO_Rsp

HO_CnfHO_Cnf

HO_Cnf

HO_ReqHO_Req

6

Figure 7-53 - HO Function Network Transaction 7

a) The Serving HO Function initiates an HO Network Transaction by sending HO_Req. There can be only one 8 Serving HO Function for any given HO Network Transaction. After receiving HO IND from MS, serving 9 HO Function the Serving HO Function confirms HO to only one Target HO Function by sending HO_Cnf. 10

b) The Target HO Function responds to the HO Network Transaction with HO_Rsp. There can be one or more 11 Target HO Functions for an HO Network Transaction. 12

c) Serving and Target HO Functions MAY communicate either directly or with assistance of one or more or 13 Relaying HO Functions. I f t he S erving a nd T arget H O F unctions c annot c ommunicate d irectly f or a ny 14 reason, the Relaying HO Functions take care o f delivering the relevant information to the corresponding 15 Target HO Functions. A single HO Primitive (e.g., HO_Req) that is sent from the Serving HO Functions 16 MAY contain information relevant for several Target HO Functions. In this case several behavioral policies 17 might be applied, for example: 18

o The Relaying HO Functions sends the relevant information in separate primitives to each Target HO 19 Function via zero o r more Relaying HO F unction. It i s the responsibility o f t he first Relaying HO 20 Functions directly in communication with Serving HO Function to get responses from the Target HO 21 Functions and compile the information into a single response, and it MAY but doesn't have to collect 22 all the responses. This situation is shown in the Figure 7-53 where one of the Relaying HO Functions 23 splits t he o riginal HO_Req into t wo o nes a nd s ends t hem t o t he T arget H O F unctions. T hen t he 24 Relaying HO Function, which has split the original HO_Req, waits for HO_Rsp from both Target 25 HO Functions and sends back a single HO_Rsp, which includes the information received from both 26 Target HO Functions. 27

o The Relaying HO Function sends the relevant information in separate primitives to each Target HO 28 Function, however it relays only the first response and drops the others. 29


Page - 132


o The R elaying H O F unction behaves l ike e xplained i n t he cas e) ab ove, however i t waits for t he 1 responses only for a l imited period of t ime and ignores those that arrived after the t ime period has 2 expired. 3

Other policies can be applied as well. 4

7.7.3.2 HO Function Primitives 5

7.7.3.2.1 HO_Req 6 This primitive is used by the Serving HO Function to inform the Target HO Functions about an incoming HO_Req 7 from an MS. 8

HO_Req delivers a t le ast the f ollowing I nformation E lements; o ther a dditional i nformation e lements M AY b e 9 included too: 10

• MS ID which identifies the MS that has requested HO. 11

• The list of the Candidate Target BS Ids. 12

• MS/Session Information Content MAY be attached to the HO_Req as well. 13

• First requested Bi-cast SDU SN. This IE is presented if it’s lossless HO and synchronization method is 14 sequence number method. It’s the Sequence Number of the earliest SDU which hasn’t been sent or Acked, 15 and need to be delivered to target DP Function. 16

7.7.3.2.2 HO_Rsp 17 The Target HO Function responds to the Serving HO Function with the list of recommended Target BSs. 18

HO_Rsp is always sent in reply to the HO_Req. It delivers the following Information Elements at least: 19

• MS ID. 20

• The list of the Recommended Target BS IDs. The list must be a subset of the Candidate Target BS IDs list 21 from the corresponding HO_Req. For each target BS in that list, service level prediction information will be 22 included. Ideally the list would contain only one Target BS ID. If the list contains more than one Target BS 23 ID the final selection of the Target BS is up to the MS. 24

• Info_Support_HO_Optimization Optional information for supporting HO Optimization. 25

• HO_ID. The optional HO_ID is assigned by Target BS. 26

• HO Action Time. The optional HO Action time is specified by Target BS for assigning Fast_Ranging_IE 27 time, and notifies MS performing re-entry network procedure. In the case TBS decides not to support it, the 28 value 0 is delivered in this parameter. 29

• First Bi-cast SDU SN. Identifies the SN of the first SDU after the data path has been changed to deal with 30 mobility. This might be used to indicate to the serving DP which is the first SDU bi-cast to the target. 31 Another use of this field is to indicate to the serving DP which is the last SDU sent before the data path 32 changed. The Serving HO Function should trigger the Serving PHY/MAC function to send MOB_BSHO-33 RSP after the announced SDU has been delivered to the MS. If the IE is omitted the Serving PHY/MAC 34 function may trigger sending MOB_BSHO-RSP at any moment. 35

7.7.3.2.3 HO Directive 36 This p rimitive is used b y t he related ASN functions to i ndicate Serving HO Function to t rigger a H O procedure, 37 such as .16e function entity, RRC or NRM Entity. HO Directive MAY deliver following Information Elements: 38

• The list of the IDs of the handover MSs which identifies the MS that has been requested HO. 39

• The list of the Candidate neighbor BSs Info: This parameter is optional and indicates the HO MS’s 40 Candidate neighbor BSs information, such as neighbor BSID, signal quality, etc. 41

• Trigger source which identifies the HO source, such as RRC, NRM, or 16e function entity. 42


Page - 133


7.7.3.2.4 HO Directive Response 1 This p rimitive i s u sed t o r eply HO Directive p rimitive, an d i ndicate t hat t he S erving H O Function have al ready 2 received the HO Directive primitives from the related function entity, such as RRC or NRM Entity. HO Directive 3 Response delivers following Information Elements: 4

• Transaction ID. 5

7.7.3.2.5 HO_Cnf 6 This primitive indicates the final HO action such as initiation, cancellation or handover rejection. It is sent from the 7 Serving HO Function to the Target HO Function and conveys at a minimum the following Information Elements: 8

• Target BS ID. 9

• MS ID. 10

• Downlink ARQ Sync Info (per Service Flow): ARQ Context that is necessary to restore communication 11 from the very point it has been interrupted. See discussion in 7.7.2.2.6.3.1. 12

• Uplink ARQ Sync Info (per Service Flow): ARQ Context that is necessary to restore communication 13 from the very point it has been interrupted. See discussion in 7.7.2.2.6.3.2. 14

Primitives/Content Elements for data flow integrity and sequence synchronization are TBD. 15

7.7.4 Data Path Function 16 Data Path ID included in Request message means opposite direction’s Data Path, and in Response message means 17 opposite direction's Data Path. 18

7.7.4.1 Data Path Function Network Transaction 19 Data Path Establishment or Release is initiated from the Anchor or Target Data Path Function and terminated by the 20 Anchor or Serving Data Path Function. 21

Data Path Function([Usually Target or

Anchor])Data Path Function

(One or More Relays)

Data Path Function(usually Anchor or

Serving)

Path_Dereg_Req

Path_Dereg_Rsp

Path_Dereg_AckPath_Dereg_Ack

Path_Dereg_Rsp

Path_Dereg_Req

22

Figure 7-54 - Data Path Function Network Transaction 23

Data Path Function MAY work in three modes: 24


Page - 134


a) Target/Anchor Mode. The Data Path Function that initiates a D ata Path Network Transaction by sending 1 Path_Prereg_Req and Path_Dereg_Req. There can be only o ne Data Path Function in Requesting Mode 2 for any given Data Path Network Transaction. 3

b) Anchor/Serving Mode. The Data Path Function that responds to the Data Path Network Transaction with 4 Path_Prereg_Rsp and Path_Dereg_Rsp. There can be only one Terminating Data Path Function for a Data 5 Path Network Transaction. 6

c) Relaying Mode. The Data Path Function that terminates incoming Path_Prereg_Req and Path_Dereg_Req 7 messages and generates n ew Path_Prereg_Req and Path_Dereg_Req messages related to the same Data 8 Path. T he s ame way it works with Path_Prereg_Rsp and Path_Dereg_Rsp message a s shown in Figure 9 7-54. 10

7.7.4.2 Data Path Function Primitives 11

7.7.4.2.1 Information Elements conveyed with Data Path Primitives 12

• Operation ID. Identifies the operation requested. There four operations: Path Registration, Path De-13 Registration and Path Pre-Registration, Path Modification. 14

• Operation Reason. Identifies the reason behind the request. The reasons MAY include but are not limited 15 to: Handover, Initial Network Entry, Entering or Exiting Idle Mode, MS loss of carrier, etc. 16

• Operation Status. Success/Failure (used only in Responses). 17

• Failure Code (if Failure). 18

• MS ID. A unique Identifier for the MS (e.g. MAC Address). Data Paths are established to convey data that 19 are either destined to / originated at an MS or an entity behind an MS. 20

• Data Path Info. It describes the Data Path in the direction opposite to that in which the primitive is sent. It 21 potentially includes: 22

o Data Path Encapsulation Type specifies the encapsulation type of the Data Path (e.g., GRE, MPLS, 23 VLAN, etc.). 24

o Data Path Type specifies the type of the Data Path (e.g., Type1 Data path, Type 2 Data path). 25

o Data Path ID specifies Data Path ID (e.g., LSP identification for MPLS, GRE Key for GRE, LAN 26 ID for VLAN, etc.). 27

o List o f C lassifier s that identify what d ata S HOULD b e c lassified o nto t he D ata P ath and a llows 28 optional negotiating Data Path IDs on per microflow (IEEE 802.16 Connection) basis. 29

o Multicast Info. Specifies relation of the Data Path to the IP Multicast Group. 30

o Endpoint Identifier . Specifies the addressable subscriber-side endpoint for which the Data Path is 31 being established or maintained. 32

o Data Integr ity operation flag: Indication if data integrity is required for this data path. 33

• Data Integrity Info: It describes the data integrity scheme used during the HO. It potentially includes the 34 following IEs: 35

o Data I ntegr ity B uffer ing M ethod: I ndication o f b uffering mechanisms: Anchor B uffering i n t he 36 Originator, Buffering in the Terminator, or Bi/Multi-Casting. 37

o Data de livery s ynchronization method: I ndication o f b uffered d ata d elivery s ynchronization 38 mechanism: sequence number enable, data retrieve with sequence number disable and Ack window 39 with sequence number disable. 40

o Data i ntegr ity op eration I D: Specifies t he o peration which r elated t o p articular d ata i ntegrity 41 mechanisms. There are 3 operations: DP_SYNC-REQ, DP_SYNC-ACK and DP_SYNC-RSP. 42


Page - 135


o First r equested Bi-cast SDU SN: The Sequence Number of the earliest SDU which hasn’t been sent 1 or Acked and need to be delivered to target DP Function. 2

o First Bi-cast SDU SN: Identifies the SN of the first SDU after the datapath has been changed to deal 3 with mobility. This might be used to indicate to the serving DP which is the first SDU bi-cast to the 4 target. Another use of this field is to indicate to the serving DP which is the last SDU sent before the 5 data path changed. 6

o Last Packet Indication. The LPI can be used in the target as an indication that all traffic from the 7 serving has b een “synchronized” an d n ormal scheduling o f t raffic ar riving from a nchor can b e 8 resumed. 9

o List of lossless session IDs: Since not all sessions for the MS requires lossless handoff, the list of 10 the lossless session IDs SHALL be included. T he session ID is the identifier which can identify a 11 unique service session in the anchor ASN DF. 12

o Data r etr ieve in fo: contains the information for data retrieving, such as number of SDU need to be 13 retrieved. 14

7.7.4.2.2 Path_Reg_Req 15 Path_Reg_Req is used to handle a registration of a MS, or a MS Flow in the Data Path Function which receives the 16 Path_Reg_Req. The r egistration r equest is a lso used for r egistering t he membership o f multicast groups 17 corresponding to the MS. It contains the following information: 18

• Operation ID. Set to Path Registration. 19

• Operation Reason. One of the reasons mentioned in 7.7.4.2.1. 20

• MS ID. As described in 7.7.4.2.1. 21

• Data Path Info. Describes Data Path for the direction from the Data Path Function that receives 22 Path_Reg_Req to the Data Path Function that sends Path_Reg_Req. The content of Data Path info is 23 discussed in 7.7.4.2.1. 24

• Anchor DP redirection Indication. It is used to indicate Anchor DP function relocation when the 25 originating DP function decide to relocate Anchor DP function directly. 26

• Data Integrity Info As described in 7.7.4.2.1. The data integrity Info IEs MAY be includes in this 27 primitives are: 28

o Data I ntegr ity B uffer ing M ethod: I ndication o f b uffering mechanisms: Anchor B uffering i n t he 29 Originator, Buffering in the Terminator or, Bi/Multi-Casting. 30

o Data s ynchronization method: I ndication o f b uffered d ata d elivery s ynchronization mechanism: 31 sequence number enable, data retrieve with sequence number disable and Ack window with sequence 32 number disable. 33

o First r equested Bi-cast SDU SN. As described in 7.7.4.2.1. 34

o Data integr ity operation ID: The three following data integrity operation ID can be carried by Path 35 Registration response: DP_SYNC-REQ: 36

− DP_SYNC-REQ: I t indicates that the indicated sessions SHOULD be lossless handoff. It is 37 sent to the serving ASN DF (from the anchor target DF to the serving ASN DF when there’s 38 direct communication between them otherwise is sent from Anchor DF) to establish the a data 39 path for retrieving data synchronization. The primitive conveys at a minimum the following 40 Information Elements. 41

− The MS ID and List of lossless session IDs are needed while this operation ID is presented. 42

For supporting IP multicasts, the primitive is used to indicate that a specific MS is part of the multicast group. 43


Page - 136


Upon r eceipt of Path_Reg_Req, t he D ata P ath F unction which r eceives Path_Reg_Req MAY begin r ecognizing 1 packets destined for the MS and forward them (using the selected Data Path enforcement mechanism) to the Data 2 Path Function which sends the Path_Reg_Req (possibly via Relaying Data Path Functions). 3

7.7.4.2.3 Path_Prereg_Req 4 Path_Prereg_Req is used during handovers in order to establish a new Data Path for an MS without destroying the 5 old one. The information the primitive delivers is identical to that of Path_Reg_Req, except from the Operation ID 6 which SHALL be set to Path Pre-Registration. 7

The Data Path Function that receives Path_Prereg_Req expects Registration Request to follow in order to complete 8 new DP establishment. 9

7.7.4.2.4 Path_Dereg_Req 10 Path_Dereg_Req is used to cancel an existing Data Paths for an MS. 11

Path_Dereg_Req contains the following information: 12

• Operation ID. Set to Path De-Registration. 13



• Data Path Info. Describes Data Path for the direction from the Data Path Function that receives 16 Path_Reg_Req to the Data Path Function that sends Path_Reg_Req. The content of Data Path info is 17 discussed in 7.7.4.2.1. Data Path Info might be omitted in the Path_Dereg_Req. It means that all the Data 18 Paths for the specified MS SHOULD be cancelled. 19

7.7.4.2.5 Path_Modification_Req 20 Path_Modification_Req is used to modify attributes of an existing Data Path. It contains the following information: 21

• Operation ID. Set to Path Modification. 22



• Data Path Info. Describes Data Path for the direction from the Terminating Data Path Function to the 25 Originating one. The content of Data Path info is discussed in 7.7.4.2.1. 26

For supporting IP multicasts, the primitive is used to indicate that a specific MS is part of the multicast group. Upon 27 receipt of Path_Modification_Req, the Terminating Data Path Function begins modify QoS Parameters, Data Path 28 Info indicated in the message to the Originating Data Path Function (possibly via Relaying Data Path Functions). 29

7.7.4.2.6 Path_Reg_Rsp 30 Path_Req_Rsp is sent in reply to the Path_Reg_Req. It contains the following information: 31


• Operation Status. Success/Failure. 33


• Data Path Info. It describes the Data Path in the direction from the Data Path Function that sends 35 Path_Reg_Req to the Data Path Function that receives Path_Reg_Req. The content of Data Path info is 36 discussed in 7.7.4.2.1. 37

• Anchor DP redirection Indication. It is used to indicate Anchor DP function relocation when the 38 terminating DP function decides to relocate Anchor DP function. 39

• Data Integrity Info As described in7.7.4.2.1. The data integrity Info IEs MAY be includes in this 40 primitives are: 41


Page - 137


o Data i ntegr ity op eration I D: The f ollowing d ata i ntegrity o peration I D ca n b e car ried b y P ath 1 Registration response: DP_SYNC-RSP: 2

− DP_SYNC_RSP: indicates t hat t he D ata P ath S ync Request message i s r eceived a nd t he 3 corresponding produce is being processed. The received downlink packets for the MS in the 4 serving D F, as well as the un-transmitted d ownlink p ackets f or th e M S in t he B S, will b e 5 returned to . I f the requester was t he Anchor D F, where a ll downlink traffic for t his MS is 6 buffered in the anchor DF till the final target DF is identified and the data path is established 7 between Anchor DF and target DF. It is sent from the serving DF to the anchor DF requester. 8 The MS ID is need while this operation ID is presented. 9

Upon r eceipt o f P ath R egistration R esponse, t he D ata P ath F unction that s ends Path_Reg_Req MAY begins 10 recognizing packets originated from MS and forwards them (using the selected Data Path enforcement mechanism) 11 to the Data Path Function that receives Path_Reg_Req MAY (possibly via Relaying Data Path Functions). 12

7.7.4.2.7 Path_Prereg_Rsp 13 Path_Prereg_Rsp is sent in reply to the Path_Prereg_Req. 14

It contains the following information: 15

• Operation ID. Set to Path Pre-Registration. 16



• Data Path Info. It describes the Data Path in the direction from the Originating Data Path Function to the 19 Terminating one). The content of Data Path info is discussed in 7.7.4.2.1. 20

• Data Integrity Info As described in 7.7.4.2.1. The data integrity Info IEs MAY be includes in this 21 primitives are: 22

o Data I ntegr ity B uffer ing M ethod: I ndication o f b uffering mechanisms: Anchor B uffering i n t he 23 Originator, Buffering in the Terminator or, Bi/Multi-Casting. 24

o Data s ynchronization method: I ndication of buf fered da ta de livery s ynchronization mechanism: 25 sequence number enable, data retrieve with sequence number disable and Ack window with sequence 26 number disable. 27

o First r equested Bi-cast SDU SN. As described in 7.7.4.2.1. 28

7.7.4.2.8 Path_Dereg_Rsp 29 Path_Dereg_Rsp is sent in reply to Path_Dereg_Req. It contains the following information: 30




7.7.4.2.9 Path_Modification_Rsp 34 Path_Modification_Rsp is sent in reply to the Path_Modification_Req. It contains the following information: 35




• Data Path Info. It describes the Data Path in the direction from the Originating Data Path Function to the 39 Terminating one). The content of Data Path info is discussed in 7.7.4.2.1. 40


Page - 138


7.7.4.2.10 Path_Reg_Ack 1 Path_Reg_Ack acknowledges the completion of a Path Registration Transaction. It contains the following 2 information: 3



• Data Integrity Info. As described in 7.7.4.2.1. The data integrity Info IEs MAY be includes in this 6 primitives are: 7

o Data integr ity operation ID: The following data integrity operation ID can be carried by 8 Path_Reg_Ack: DP_SYNC-ACK: 9

− DP_SYNC-ACK: It indicates that the completion of the retrieve data path establishment. It is 10 sent to th e s erving D F f rom th e ta rget D F it t here’s d irect c ommunication a mong th em, 11 otherwise it is sent from the anchor DF. The MS ID and Data retrieve IE are need while this 12 operation ID is presented. 13

Upon receipt of Path_Reg_Ack which indicates the completion of f inal data path registration transaction, the Data 14 Path F unction which receives Path_Reg_Req MAY b egin recognizing p ackets destined f or the MS and f orwards 15 them (using the selected Data Path enforcement mechanism) to the Data Path Function which sends the 16 Path_Reg_Req (possibly via Relaying Data Path Functions) if this action hasn’t been started. 17

7.7.4.2.11 Path_Dereg_Ack 18 Path_Dereg_Ack acknowledges t he co mpletion o f a P ath De-Registration T ransaction. It c ontains t he following 19 information: 20



7.7.4.2.12 Path_Prereg_Ack 23 Path_Prereg_Ack acknowledges the co mpletion o f a Path Pre-Registration T ransaction. I t contains t he f ollowing 24 information: 25

• Operation ID. Set to Pre-Registration. 26


7.7.4.2.13 Path_Modification_Ack 28 Path_Modification_Ack acknowledges the completion of a Path Modification Transaction. It contains the following 29 information: 30



7.7.4.2.14 Data-ACK 33 If th e d elivery s cheme o f d ata in tegrity u ses Ack window, This p rimitive is s ent from s erving D ata function to 34 Anchor DF to indicate the sequence number of the SDU which has been Acked. 35


Page - 139


7.7.4.3 Simultaneous Data Path Establishment by Both Peers 1 The peer Data Path Functions may instigate Data Path Establishment for the same MS simultaneously as shown on 2 the Figure 7-49. 3

Data PathFunction 1

Data PathFunction 2

Path_Prereg_Req[DP Info = X]

Path_Prereg_Req[DP Info = Y]

Path_Prereg_Rsp[DP Info = X]

Path_Prereg_Rsp[DP Info = Y]

Path_Prereg_Ack

Path_Prereg_Ack

4

Figure 7-55 - Both Peers Establish Data Path Simultaneously 5

When such condition take place both peers follow the following rule: 6

Both Path_Prereg_Req and Path_Prereg_Rsp that are sent in the same direction and refer to the same Data 7 Path should convey the same Data Path Info. 8

This rule utilizes the fact that, in accordance with the definition in 7.7.4.2.1, each peer independently specifies Data 9 Path Info for its respective reception direction and this is why such a collision does not really create a race condition. 10

In t he s ituation shown on t he F igure 7 -49, i t i s e nough i f onl y on e o f t he Data P ath Establishment t ransactions 11 succeeds. 12

7.7.4.4 Target Centric Pre-Registration and Registration during HO 13 Target Centric refers to an approach according to which the Target DP Function instigates both Pre-Registration and 14 Registration Transactions during HO. 15

Path Pr e-Registration T ransaction ( Path_Prereg_Req and Path_Prereg_Rsp and Path_Prereg_Ack) i s i nvoked i n 16 order t o es tablish a D ata P ath for an M S b etween t he Anchor D P F unction an d T arget D P F unction without 17 destroying the Data Path between the Anchor DP Function and Serving DP Function for the same MS. 18


Page - 140


It is allowed to pre-register simultaneous Data Paths between the same Anchor DP Function and multiple Target DP 1 Functions. 2

Pre-establishing Data Paths between the Anchor DP Function and Target DP Functions does not affect forwarding 3 data along the Data Path between the Anchor DP Function and Serving DP Function. 4

By default when a Data Path between the Anchor DP Function and a Target DP Function is established the data are 5 not forwarded along this Data Path. However other traffic handling options might be negotiated during Path. The 6 data may be forwarded a long t he pr e-established Data P ath b etween the Anchor D P Function an d a T arget D P 7 Function simultaneously with data forwarding along the Data Path between the Anchor DP Function and the Serving 8 DP F unction. Alternatively t he d ata may b e b uffered for t he p re-established D ata P ath b etween t he Anchor D P 9 Function and a Target DP Function in order to be delivered later upon request. These traffic delivery options are part 10 of the Data Integrity framework. 11

Path Registration Transaction is invoked when a new Serving Data Path between Anchor DP Function and the DP 12 Function which is a Target DP Function upon beginning of the Transaction and which becomes the new Serving DP 13 Function upon completion of the Transaction. I t should not happen earlier than MS arrives to the Target BS/ASN 14 (with which the Target DP Function is associated). 15

At t he moment t he Anchor D P F unction receives Path_Reg_Req from a T arget D P Function (which is a bout to 16 become the new Serving DP Function) i t should s top forwarding data a long the Data Path to the old Serving DP 17 Function. Shortly after that the Anchor DP Function shall De-Register the Data Path to the old Serving DP Function. 18 The Serving DP Function may a lso instigate P ath De-Registration i f it le arns from HO Function t hat t he MS has 19 completed HO in the Target BS/ASN. 20

Path Pre-Registration Transaction may be executed prior to Path Registration Transaction (for the same data path). If 21 Path Pr e-Registration T ransaction has b een c ompleted p rior to s tarting P ath Registration T ransaction t hen t he 22 purpose of the Path Registration Transaction is only to trigger “data path switch”. In this case Path_Reg_Req and 23 Path_Reg_Rsp do not have to convey any Informational Elements except from MS ID and, optionally, Data Path ID. 24 The rest of the parameters that are relevant to the data path have to be exchanged during the preceding Path Pre-25 Registration T ransaction. F urthermore i n t his ca se P ath R egistration T ransaction i s co mpleted with t wo-way 26 handshake – Path_Reg_Req and Path_Reg_Rsp exchange without Path_Reg_Ack. 27

As it has been mentioned above, by default the Anchor DP Function does not forward data to a Target DP Function 28 along the corresponding pre-established Data Path (unless a different traffic forwarding option was negotiated upon 29 the Data Path P re-Registration) In t his case the Anchor D P Function may s tart forwarding data to t he T arget DP 30 Function i mmediately after i t r eceives Path_Reg_Req. The Target DP Function may start f orwarding d ata to t he 31 Anchor DP Function immediately after it receives Path_Reg_Rsp. 32

Figure 7-56 shows the typical sequence for Pre-Registration, Registration and De-Registration Transactions as they 33 likely to occur during HO. 34


Page - 141


Serving DP Function

Anchor DP Function

Target DPFunction 1

Target DPFunction 2

Path_ Prereg_Req

Path_ Prereg_Req

Path_ Prereg_Rsp

Path_ Prereg_Rsp

Path_ Prereg_Ack

Path_ Prereg_Ack

Path_Reg_Req

Path_Reg_Rsp

Path_ Dereg_Req

Path_ Dereg_Rsp

Path_ Dereg_Req

Path_ Dereg_Rsp

Path_ Dereg_AckPath_ Dereg_Ack

1

Figure 7-56 - Target Centric DP Control Transactions (with Pre-Registration) during HO 2

If Path Registration T ransaction s tarts without a ny p receding Path P re-Registration T ransaction, then Registration 3 Request and Response shall convey all Informational Elements that contain parameters relevant for the data path to 4 be established. In this case Path_Reg_Ack shall be sent in response to Path_Reg_Rsp. Still, the Anchor DP Function 5 may start forwarding data to the Target DP Function immediately after i t receives Path_Reg_Req. The Target DP 6 Function may start forwarding data to the Anchor DP Function immediately after it receives Path_Reg_Rsp. 7

Shortly after completing Path Registration Transaction, Anchor DP Function should De-Register the Data Path to 8 the o ld S erving DP F unction. Figure 7-57 shows t he t ransactions i nvolved. T he S erving D P F unction may a lso 9 instigate Path De-Registration if it learns from HO Function that the MS has completed HO in the Target BS/ASN. 10


Page - 142


Anchor DP Function

Target DP Function

Serving DP Function

Path_ Dereg_Rsp

Path_ Dereg_Req

Path_Reg_Ack

Path_Reg_Rsp

Path_Reg_Req

Path_ Dereg_Ack

1

Figure 7-57 - Target Centric DP Control Transactions (without Pre-Registration) during HO 2

3


Page - 143


7.7.4.5 Anchor Centric Pre-Registration and Registration during HO 1 Anchor C entric r efers t o an ap proach acco rding t o w hich t he Anchor D P F unction i nstigates P re-Registration 2 Transaction. Registration Transaction however is still instigated by the Target HO Function because the Transaction 3 should not start earlier than MS registers with the Target BS (with which the Target DP Function is associated). 4

The message processing rules are identical to the rules discussed for the Target Centric approach. Figure 7 52 shows 5 the t ypical s equence for P re-Registration, R egistration a nd D e-Registration T ransactions a s t hey li kely to o ccur 6 during HO. 7

Serving DP Function

Anchor DP Function

Target DP Function 1

Target DP Function 2

Path_ Dereg_Rsp

Path_ Dereg_Req

Path_ Prereg_Rsp

Path_ Prereg_Req

Path_ Prereg_Req

Path_ Prereg_Rsp

Path_ Prereg_Ack

Path_ Dereg_Req

Path_ Dereg_Rsp

Path_Reg_Req

Path_Reg_Rsp

Path_ Prereg_Ack

Path_ Dereg_Ack

Path_ Dereg_Ack

8

Figure 7-58 - Typical Anchor Centric DP Control Transactions during HO 9


Page - 144


7.7.5 Context Delivery Function 1 Context Client MAY request from the Context Server the Session/MS Context (or parts of it). 2

The Session Info Context MAY include any or all of the following: 3

• MS NAI 4

• MS MAC Address 5

• Anchor ASN GW associated with the MS 6

• List of Service Flow IDs with associated: 7

o SF Classifiers 8

o SF QoS 9

o CID (associated with the SFID) 10

o Data Path tagging (ID) Information 11

o Etc. 12

• R3 related information 13

o Home Agent IP address 14

o CoA 15

o DHCP Server 16

o AAA Server 17

o R3 status Details 18

• Security Information 19

o Security information related to PKMv2 (e.g., SAs and i ts contexts including TEK, l ifetime and PN 20 etc.) 21

o Security information related to Proxy MIP (if used) 22

7.7.5.1 Context Delivery Primitives 23

7.7.5.1.1 Context_Req 24 This primitive is used by a network entity to request the session information of a given MS from another network 25 entity. 26

Context_Req contains type identifiers of the requested Informational Elements belonging to an MS's session context. 27

The Context_Req MAY be used multiple times to derive the set of information required from multiple entities. For 28 example, the security information MAY be delivered via an authenticator. 29

7.7.5.1.2 Context_Rpt 30 Context_Rpt might be sent unsolicited or in response to the Context_Req. 31

The entity t hat received the Context_Req SHALL respond with t he Context_Rpt and include in the response t he 32 Informational Elements that have been specified in the Context_Req. 33

The Context Server MAY lack some information requested by the Context Client. Thus the Report does not have to 34 contain a ll the Informational Elements requested with the Context_Req. I f the Context Server lacks any requested 35 information it SHALL send an empty Report. 36

The Context_Rpt MAY be unsolicited attached to the HO Control primitives. 37


Page - 145


7.7.6 Cooperation between the Functions 1 The Functions described i n t he s ections a bove t rigger e ach o ther’s o perations b y issuing i nternal t riggers t o o ne 2 another. W ith t hose triggers th e in formation d elivered with p rimitives o f o ne Function might be us ed in t he 3 operations of another Function. 4

The tr iggers a re o ut o f s cope o f S tage 2 a nd a re mentioned o nly to facilitate e xplanation o f the I nter-Function 5 Cooperation. This Cooperation would depend on the actual placement of the Functions. Thus, only examples of 6 Inter-Function Cooperation are given here. 7

Figure 7-59 and Figure 7-60 shows possible Inter-Function Cooperation in an ASN. 8


Page - 146


MS M

OB

_MS

HO

_RE

Q

Trg Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Trg

Ser

ving

.16e

Fn

Ser

ving

HO

FnC

onte

xtC

lient

Fn

HO

_Rel

ay Fn

Targ

et.1

6e F

nTa

rget

HO

FnTa

rget

DP

FnC

onte

xtC

lient

Fn

Key

Rcv

rR

elay

DP

FnA

ncho

r DP

FnC

onte

xtS

erve

r Fn

Key

Dis

tribu

tor

Con

text

_Req

Con

text

_Req

Con

text

_Rpt

Con

text

_Rpt

Con

text

_Rpt

Con

text

_Req

Key

Req

uest

Key

Req

uest

Key

Tra

nsfe

r

Key

Tra

nsfe

r

Pat

h_P

rere

g_A

ck

Pat

h_P

rere

g_R

eq

Pat

h_P

rere

g_R

sp

Pat

h_R

eg_R

eq

Pat

h_R

eg_R

sp

Pat

h_R

eg_A

ck

Pat

h_R

eg_R

eq

Pat

h_R

eg_R

sp

Pat

h_R

eg_A

ck

Pat

h_P

rere

g_A

ck

Pat

h_P

rere

g_R

eq

Pat

h_P

rere

g_R

sp

HO

_Req

HO

_Rsp

RN

G-R

SP

RN

G-R

EQ

HO

_Cnf

HO

_Req

HO

_Rsp

HO

_Cnf

MO

B_M

SH

O_R

SP

MO

B_H

O_I

NG

Serv

ing

DP

Fn

Pat

h_D

ereg

_Req

Pat

h_D

ereg

_Rsp

1


Page - 147


Figure 7-59 - Cooperation between the Functions (Example) 1

ServingHO Fn

Serving.16e FnMS

MOB_MSHO_REQ

MOB_MSHO_RSP

MOB_HO_IND

Trg

Trg

Trg

Trg

Trg

Trg

TrgTrg

Trg

Trg

Trg

Trg

Trg

Trg

RNG-REQ

RNG-RSP

HOFn(s)

ContectClient Fn

Target.16e Fn

TargetHO Fn

TargetDP Fn

ContectClient Fn

KeyReceiver

RelayDP Fn

AnchorDP Fn

ContextServer Fn

KeyDistributor

additionaltransactions forcontext retreval

(if needed)

Reg_Req

Reg_Rsp

Key Transfer

Context_Rpt

Context_Rpt

Context_Rpt

Context_Rpt

Reg_Req

Reg_Rsp

Context_Req

Context_Req

HO_ReqHO_Rsp

HO_Cnf

HO_Req

HO_Rsp

HO_Cnf

ServingDP Fn

Path_Dereg_Rsp

Path_Dereg_Req

Reg_AckReg_Ack

2

Figure 7-60 - Cooperation between the Functions (Example2) 3

Figure 7-59 and Figure 7-60 show example scenarios of Mobile Initiated HO: 4

The MS sends MOB_MSHO-REQ to the Serving .16e Function, which in turn triggers the Serving HO Function to 5 send HO_Req to the Target HO Function(s) via the Relay HO Function(s). 6

The Context retrieval transaction MAY be performed at different points in the HO procedure by different Functional 7 Entity, in d ifferent i mplementations. T he th ree t ypical p oints a re: b efore tr ansmitting HO_Req to T arget H O 8 Function, after receiving HO_Req by Target HO Function, and before transmitting HO_Cnf to Target HO Function. 9

In a n option, pr ior t o s ending t he HO_Req to t he T arget H O F unction(s), t he S erving H O Function ( as i n the 10 example 1) or the Relay HO Function (as in the example 2) MAY trigger its associated Serving Context Client to 11 request required MS Context (via Context_Req and Context_Rpt Transaction) which is to be delivered to the Target 12


Page - 148


HO Function with HO_Req. It is also possible that a part of the MS Context is delivered here and the other parts are 1 delivered later in time (e.g., when transmitting HO_Cnf). 2

When HO_Req arrives to the Target HO Function the latter MAY trigger the associated Context Client Function to 3 send Context_Req in o rder t o r etrieve t he necessary M S C ontext, i f t he r eceived HO_Req does no t ha ve such 4 Context information (as in the example 1). In this case, the Security Context (e.g., AK, PN associated with AK, etc.) 5 MAY a lso b e retrieved using the K ey Distribution Protocol. The MS C ontext an d K ey D elivery t ransactions are 6 optional at this stage. Alternatively these transactions MAY be conducted later when the Serving HO Function or 7 one of Relay HO Functions transmits the HO_Cnf to the Target HO Function. 8

If all necessary MS Context is available in the Target BS(s), then the Data Path Function MAY Pre-Register with 9 the Anchor DP Function via the Relay DP Function(s). T his step is optional and i s needed only i f the Data Path 10 between the Anchor DP Function and the Target DP Function has to be established prior to removing the Data Path 11 between t he Anchor D P F unction a nd t he Serving D P F unction ( e.g., for bi -casting). W hen the o ptional P re-12 Registration is completed the Target DP Function triggers the Target HO Function. 13

Then the Target HO Function sends HO_Rsp to the Serving HO Function. 14

Upon r eceiving the HO_Rsp the S erving HO function t riggers t he . 16e F unction to r espond t o t he M S with 15 MOB_BSHO-RSP. 16

When the MS is about to leave the Serving .16e Function i t sends MOB_HO-IND. The Serving .16e Function in 17 turn triggers the Serving HO Function to send HO_Cnf to the Target HO Function via the Relay HO Function(s). 18 Optionally t he MS Context and K ey Delivery T ransactions might b e c onducted here, a nd t he c ontext a nd key 19 information are to be delivered to the Target HO Function with HO_Cnf. 20

When HO_Cnf arrives to the T arget HO Function t he la tter tr iggers t he T arget .16e Function to s tand b y for MS 21 Network Re-Entry. 22

And the Target HO Function triggers the Target DP function to Register Data Path with the Anchor DP Function via 23 the Relay DP Function(s), if it receives HO_Cnf with MS context and a Data Path has not been made yet. (If needed, 24 the Target HO Function MAY trigger the Context Client to make an additional Context retrieval transaction, before 25 it triggers Target DP Function). 26

When Registration is completed the Data Path between the Anchor DP Function and the Old Serving DP Function is 27 removed a nd o nly the D ata Path b etween t he Anchor D P F unction a nd t he T arget ( New S erving) D P F unction 28 remains. 29


Page - 149


7.7.6.1 Data Integrity HO Mechanism 1

7.7.6.1.1 Anchor DF Buffering with Sequence Number 2

Buffering

Start Data forwarding (from N+1)

MS

MOB_MSHO-REQ

PHY/MACFunction

ServingDP

FunctionHO_Fun

ctionPHY/MACFunction

TargetDP

FunctionHO_Fun

ctionDP

Function

Data Path Anchor

Path_Prereg_Req

Path_Prereg_Rsp

Path_Reg_Rsp

Path_Reg_Req (last Ack SDU N)

HO_Cnf

HO_Rsp

HO_Req

MOB_BSHO-RSP

MOB_HO-IND

3

Figure 7-61 - Anchor Data Path Function Buffering with SDU Sequence Numbering 4


Page - 150


7.7.6.1.2 Anchor DF Bi/Multi-casting with Sequence Number 1

Bi/multi-cast data start from request SN

PHY/MACFunction

ServingDP

FunctionHO_

FunctionPHY/MACFunction

TargetDP

FunctionHO_

FunctionDP

Function

Data Path Anchor

MOB_MSHO-REQ

Path_Reg_Rsp

HO_Rsp

Path_Reg_Req

MOB_BSHO-RSP

MOB_HO-IND

MS

Start forward packet to MS starting from sdu segment SN

HO_Req (request bi-casting SDU SN )

HO_Cnf (sdu segment/ARQ sync SN )

Path_Prereg_Req (data integrity inforeq bi-cast SN)

Path_Prereg_Rsp (data integrity info)

2

Figure 7-62 - Anchor Data Path Function Bi-Cast with SDU Sequence Numbering8

8 The Target DP Function may be required to buffer the DL packets, once the Anchor DP Function starts bi-casting the traffic.

3


Page - 151


7.7.6.1.3 Serving & Target Data Path Function Buffer Transferring 1

MSPHY/MACFunction

ServingDP

FunctionHO_


TargetDP

FunctionHO_

FunctionDP

Function

Data Path Anchor

MOB_MSHO-REQ

HO_Cnf

HO_Rsp

HO_Req

MOB_BSHO-RSP

MOB_HO-IND

Path_Reg_Rsp (DP-SYNC-REQ, latest sync info)

Path_Reg_Rsp (DP-SYNC-RSP)

Forward remaining/Sync data to Target

Path_Reg_Rsp (DP-SYNC-ACK)

Path_Reg_Rsp

Path_Reg_Rsp

Path_Prereg_Req

Path_Prereg_Rsp

2

Figure 7-63 - Serving Data Path Function Bi-cast to Target9

9 The Target DP Function may be required to buffer the DL packets, once the Anchor DP Function starts bi-casting the traffic.

3


Page - 152


7.7.6.1.4 Anchor & Target Data Path Function Buffer Transferring 1

MS PHY/MACFunction

ServingDP

FunctionHO_


TargetDP

FunctionHO_

FunctionDP

Function

Data Path Anchor

MOB_MSHO-REQ

HO_Cnf

HO_Rsp

HO_Req

MOB_BSHO-RSP

MOB_HO-IND

Anchor DF start forwarding Packet to TDF

Service DF transfer remaining data back to Anchor DF

Path_Prereg_Rsp (data integrity info)

Path_Prereg_Req (data integrity info)

Path_Reg_Rsp

Path_Reg_Ack

Start DataBuffing

Path_Reg_Ack (DP_RETRIEVE-ACK)

Path_Reg_Rsp (DP_SYNC-RSP)

Path_Reg_Req (DP_SYNC-REQ)

Path_Reg_Req

2

Figure 7-64 - Data Retrieval into Anchored Buffer and Data Forwarding to Target 3


Page - 153


7.7.6.1.5 Buffering with Ack Window 1

Buffering

Start Data forwarding

MS

MOB_MSHO-REQ

PHY/MACFunction

ServingDP

FunctionHO_


TargetDP

FunctionHO_

FunctionDP

Function

Data Path Anchor

Path_Prereg_Req

Path_Prereg_Rsp

Path_Reg_Rsp

Path_Reg_Req

HO_Cnf

HO_Rsp

HO_Req

MOB_BSHO-RSP

MOB_HO-IND

Ack window msg

2

Figure 7-65 - Data Path Anchor Buffering with Sliding Window Forwarding 3


Page - 154


7.7.7 Reattachment for Fixed/Nomadic Access 1 The S erving B S is th e d ecision p oint f or F ixed/Nomadic MS’s mobility Restriction when it maintains th e S S’s 2 mobility acces s c lassifier an d i ts R eattachment Zone i f one ex ists o therwise it is th e A uthenticator. T he S S’s 3 mobility access classifier and the Reattachment Zone information are transferred by the Serving BS to the Target BS 4 during r eattachment. Figure 7-66 shows a r eattachment p rocedure t o a Target B S. R eattachment u ses t he AS N 5 Mobility M anagement p rocedures as i s, ex cept i mpacting t he H O p reparation p hase o r t he co ntext r etrieval 6 procedures as described below. 7

MS Serving ASN Target BS Authenticator

ASNAnchor ASN

1. MOB_MSHO_REQ(Target BS ID List)

2b. HO_REQ(Mobility Classifier/Reattachment Zone)

5. HO_RSP6. MOB_BSHO_REQ/

MOB_BSHO_RSP (Target BS ID List)

Target ASN

7. HO_ACK

4. Data path pre-Reg

1. Network Reattachme

nt Trigger

3. MS Context Retrieval2a. MOB_BSHO_RSP

(Target BS ID =NULL)

8

Figure 7-66 - Reattachment Procedure for a Fixed or Nomadic MS 9

STEP 1 10

The MS may at tempt a handover p rocedure by sending a MOB_MSHO-REQ message t o the Serving ASN which 11 includes one or more potential Target BS’s from i ts allowed list of potential target BSs given to the MS/SS as its 12 scanning neighbor list. 13

Alternatively, a reattachment procedure at the Serving ASN is triggered by some network element such as the RRM 14 Function to improve the quality of a connection or for the purpose of load balancing. 15

STEP 2 16

The serving ASN realizes that the SS has a fixed or nomadic mobility access classifier type. It determines based on 17 the Reattachment zone whether a candidate target BS for reattachment exists. 18

STEP 2a 19

If n o accep table t arget B S e xists, a nd for t he cas e o f MS i nitiated handover at tempt, t he Serving ASN s ends a 20 MOB_BSHO-RSP message to the MS containing no potential target BS to deny the handover attempt. In the case of 21 network initiated reattachment, no further action is required. 22


Page - 155


STEP 2b 1

If an accep table Target BS exists, t he Serving ASN sends an R4 HO_Req message to one o r more Target ASNs 2 controlling the candidate target BS’s selected for the reattachment and starts timer T R4_HO_Request for each message. 3 The m essage i ncludes an Authenticator I D TLV that p oints to th e A uthenticator/Key Distributor f unction a t th e 4 Authenticator ASN and the Anchor ASN GW ID of the Anchor Data Path function at the Anchor ASN. 5

The mobility access classifier and the reattachment zone are transferred in the HO_Req message to the Target BS. 6

STEP 3 7

The authenticator shall deny context retrievals from the BSs that do not belong to the Reattachment Zone and hence 8 are not allowed to serve the fixed/nomadic SS. 9

The rest of the procedure is the same as normal ASNMM procedures. 10

7.8 CSN Anchored Mobility Management 11

7.8.1 Scope and Requirements for CSN Anchored Mobility (MIP4) Management 12

7.8.1.1 Scope 13 This section describes mobile IP based macro mobility between the ASN and CSN across the R3 reference point. In 14 the case of IPv4, this implies re-anchoring of the current FA to a new FA and the consequent binding updates (or 15 MIP re-registration) to update the upstream and downstream data forwarding paths. The procedures described in this 16 section complement the procedures outlined in Section 7.7 (where ASN- anchored mobility management procedures 17 are discussed without changes to the anchor FA in the case of IPv4). 18

The WiMAX mobility solution consists of two mobility levels: 19

• ASN-anchored mobility or micro mobility is when the MS moves between Data Path Functions while 20 maintaining the same anchor FA sitting at the northbound edge of the ASN network. The data flow 21 between CSN and Data Path Functions pivots at the anchor FA. CSN is unaware of any mobility that 22 occurs between ASN Data Plane Functions. This scenario is covered in Section 7.7. 23

• CSN Anchored Mobility Management or macro mobility is when the MS changes to a new anchor FA. 24 The new FA and CSN exchange signaling messages to establish data forwarding path10

The following additional considerations apply for R3 mobility management: 27

. This chapter 25 describes the solution for this type of mobility. 26

• CSN Anchored Mobility Management SHALL be established between ASN and CSN that are in the same 28 or different administrative domains. 29

• The mobility management MAY extend to handovers across ASNs in the same administrative domain. (See 30 Figure 7-67). 31

• Inter-technology handovers are outside the scope of this release. 32

The CSN Anchored Mobility Management procedures MAY not be synchronized with the event of MS changing its 33 point of attachment to the ASN. In other words, the procedures MAY be delayed relative to the completion of link 34 layer handover by the MS. 35

Figure 7-67 illustrates the CSN Anchored Mobility Management scope for IPv4 based mobile IP. In an intra NAP 36 R3 mobility c ase, a M S is mobile between FAs within a single NAP do main. As shown, the R3 mobility event 37 results in a handover between two FAs, thereby relocating the ASN R3 reference anchor point in the NAP. 38

Note that Inter-NAP R3 mobility is not supported in Release1. 39

10 The scope of this version of the document only covers the inter/intra-ASN handover (R3 mobility) between FAs belonging to the same NAP.


Page - 156


ASNNetwork

BS

BS

FA

NAP 2

HA

NSPHA

NSP

NAP

MS

NAP 1

MS

ASNNetwork

BS

BS

FAASNNetwork

BS

BS FA

FA

ASNNetworkBS FA

Intra-NAP R3 mobility Inter-NAP R3 mobility

1

Figure 7-67 - R3 Mobility Scope 2

7.8.1.2 Functional Requirements 3 The following functional requirements have been identified for CSN Anchored Mobility Management: 4

• CSN Anchored Mobility Management for IPv4 SHALL be based on [43] and related RFCs. Proxy-MIP 5 differs from client-based MIP in that the ASN network performs the role of the Mobile Node (MN). 6

• R3 mobility SHALL NOT automatically terminate or otherwise interfere with idle/sleep mode of operation 7 of the MS. CSN Anchored Mobility Management SHALL accommodate the scenario in which MS 8 remains in idle/sleep state until it is ready to send upstream traffic or is notified of downstream traffic from 9 the network and relinquishes the idle/sleep state. 10

• Reverse tunneling between ASN and CSN SHALL be supported. 11

• In all non-roaming scenarios, the HA SHALL be located in the CSN of Home-NSP. For roaming scenarios, 12 the HA MAY be located in the CSN of either the Home-NSP or Visited-NSP depending on: 13

o Roaming agreement between Home-NSP and Visited-NSP. 14

o User subscription profile and policy in Home-NSP. 15

• CSN Anchored Mobility Management within a single NAP administrative domain SHALL introduce 16 minimal latency and packet loss. 17

• Make-before-break operation (when coupled with ASN-anchored mobility procedures described in Section 18 0) SHOULD be possible within the same NAP administrative domain. To accomplish this, the previous 19 anchor SHOULD be capable of maintaining continuous data flow while signaling to establish the data path 20 to a new anchor FA. 21

• It SHALL be possible to generate triggers to re-anchor at any time independent of ASN-anchored mobility. 22

• From a MIP point of view an MS SHALL always operate as if in a foreign network. 23

• Both the CMIP and PMIP mobility schemes are mandatory. 24

• Efficient use of wireless link. Extra overhead over the air-interface to accomplish CSN Anchored Mobility 25 Management SHALL be minimized. 26


Page - 157


7.8.1.2.1 PMIP-Specific Functional Requirements 1

• PMIP procedures SHALL NOT require additional signaling over the air or additional data headers to 2 complete CSN Anchored Mobility Management. 3

• MS SHALL be unaware of CSN Anchored Mobility Management activities. 4

• Use of DHCP by the MS for IP address assignment and host configuration SHALL be supported. 5

7.8.1.2.2 CMIP4-Specific Functional Requirements 6

• MIP [43] specified procedures SHALL be used on MS for IP address assignment and host configuration. 7

7.8.1.3 R3 Mobility Security Requirements 8

7.8.1.3.1 Intra-domain Security 9

• When FA and HA are in the same administrative domain a trust relationship (via established FA-HA 10 security association) is assumed between the FA and HA. The set of the FA-HA security associations is an 11 implementation and/or operational issue that are outside the scope of this specification. 12

7.8.1.3.2 Inter-domain Security 13

• FA and HA, which are in different administrative domains, need to set up a trust relationship for mobility 14 signaling. 15

• Mobility service authorization for MS is needed to set-up data forwarding. 16

• Signaling between ASN and CSN SHOULD be secure: 17

o For PMIP, the H-AAA will derive the PMIP MN-HA key for a particular MS to the ASN during 18 network access authentication process. T he PMIP MN-HA key is unique for each MS; key sharing 19 between MS SHALL NOT be allowed. 20

o Mobility service key is used to set up forwarding path via dynamically established tunnels between 21 FA and HA. 22

o User Data encryption is out of the scope of this document. 23

o The choice of authentication methods SHALL comply with [43]. F or example, HMAC_SHA1 can 24 be applied to protect the signaling for now. More importantly, authentication mechanism SHALL be 25 extensible to support future cryptography. 26

7.8.1.4 CSN anchored mobility (R3 Mobility) 27 This section describes requirements and procedures for Mobile IPv4 based R3 mobility management. 28

Mobile I P ( MIP, R FC 3344 and r elated R FCs for I Pv4) i s a dopted a s t he mobility management pr otocol f or a ll 29 applicable u sage/deployment scenarios r equiring s eamless inter-subnet/inter-prefix l ayer-3 ha ndovers. W ithin the 30 Mobile IP framework, an MIP cl ient maintains a persistent Home IP address when handing o ff between different 31 FAs. The R3 Mobility solution has four functional components - a MIP client, an Foreign Agent (FA) located in the 32 access n etwork, a H ome Agent ( HA) typically located i n t he user’s h ome network ( but M AY b e d ynamically 33 assigned/requested from a visited operator’s network) and an AAA server. 34

For CSN Anchored Mobility Management two variants of the MIP protocols are supported: 35

• Client MIP (CMIP): CMIP is an IETF compliant MIP solution based on a Mobile IP enabled MS. CSN 36 Anchored Mobility Management will cover CMIP based mobility schemes for IPv4 and IPv6. 37

• Proxy MIP (PMIP): Proxy MIP is an embodiment of the standard Mobile IP framework in which an MN is 38 transparently instanced in the access network on behalf of a client that is not MIP-aware or MIP-capable. 39


Page - 158


7.8.1.5 CSN Anchored Mobility Management triggers 1 The following types of event can trigger the procedure: 2

• MS mobility: The MS hands off to a new Base Station under a new FA. 3

• Wake-up from idle mode: The MS wakes up from the idle mode at a different ASN than the one under 4 which it entered the idle mode. 5

• Resource optimization: The network decides for resource optimization purposes to transfer the R3 endpoint 6 for the MS from the serving FA to a new FA, independently of any MS movement. 7

7.8.1.6 MIP Extensions 8 The following standards SHALL be used for Mobile IPv4 operations with any limitations or extensions described in 9

this document: 10

- Mobility support for IPv4 [43] 11

- Reverse Tunneling [29] 12

- NAI Extension [22] 13

- Registration Revocation [45] 14

The following standards MAY be used for Mobile IPv4 operations with any limitations or extensions described in 15 this document: 16

- Foreign Agent Challenge [28] 17

- Mobile IP Vendor/Organization Specific Extensions [33] 18

7.8.1.7 Addressing Support 19

7.8.1.7.1 Private HoA Address Support 20 It is possible that two different MS served by the same FA have the same, overlapping private address because they 21 belong to two different private networks. 22

7.8.1.7.2 Dynamic Home Agent Assignment 23 In r oaming cas es t he H ome A gent can b e as signed b y ei ther t he H ome N SP o r t he V isited N SP. I t’s t he h ome 24 operator t hat will d ecide b ased o n t he r oaming a greement with the visited o perator an d/or t he e nd-user’s 25 subscription profile which network is responsible for assigning the MIP Home Agent. 26

If a H ome Agent is assigned in the visited network the MIP authentication will take place between the visited HA 27 and the Home AAA server. Security exchanges are transparent to the visited AAA proxy. 28

If the HA is to be assigned by the Home CSN both the Home Agent address and optionally the DHCP server address 29 or HoA address are appended to the AAA reply by the Home-AAA server. 30

For Home Agents in the Visited CSN the AAA proxy can append the Home Agent address and the optional DHCP 31 server address or HoA address to the AAA exchange between the home AAA server and the authenticator. 32

For static agreements between two operator domains (e.g., HA always in the visited network) the AAA proxy can be 33 configured to add a HA address based on the Home-AAA server domain. 34

For more dynamic Home Agent location algorithms (e.g., based on subscription profile) the AAA proxy decision to 35 append the HA address will depend on the presence of the HA address container in the AAA reply from the home 36 AAA. 37

Although not considered very scalable the address of a HA in the visited network can be provided by the home AAA 38 server based on pre-configured information. 39

The Home Agent can be provided in the form of an IP address or a FQDN (Fully Qualified Domain name). 40


Page - 159


7.8.1.7.3 Dynamic HA: PMIP Considerations 1 The PMIP security information is always exchanged between the Home AAA server and the authenticator. 2

The PMIP client will insert the HA address retrieved during the access authentication step in the MIP Registration 3 Request. 4

7.8.1.7.4 Dynamic HA: CMIP Considerations 5 The ne twork S HALL s upport d ynamic H A a llocation a lgorithm. When the FA r eceives a n R egistration Request 6 from the MS with an H A I P address value of 0.0.0.0, the HA will be assigned based on the AAA HA a ttribute 7 downloaded during the access authentication step and i ts HoA address returned in the Home Address field o f the 8 RRP. 9

7.8.1.7.5 MIP Addressing 10 The FA SHALL support [22] NAI extension. 11

If t he H A ad dress p rovided b y t he C MIP cl ient is different from t he H A ad dress downloaded d uring acces s 12 authentication t he FA M AY decide ( depending o n o perator p olicies) to f orward th e R egistration Request to th e 13 dynamically assigned HA unicast address. The HA MAY accept the Registration Request contrary to [43] or MAY 14 reject it with an error code of 136 in accordance to [43]. The HA SHALL put its own IP address in the Registration 15 Reply. The FA SHALL use a publicly routable and visible address as the CoA address. 16

7.8.1.8 Proxy MIP R3 Mobility Management 17 Proxy-MIP R3 mobility is based on MIP signaling between MIP client, FA and the Home Agent. In the proxy-MIP 18 approach the MIP client resides within the ASN network and performs R3 mobility management on be half of the 19 MS. Co -location between the proxy-MIP instance and the Authenticator functional entity in the ASN is assumed; 20 i.e., any communication between these two entities is beyond the scope of this document. The R3 mobility FA is 21 located at the northbound boundary of the ASN. The Home agent is located in a CSN network. 22

Proxy-MIP does not put additional requirements on the MS in order to support R3 mobility and is fully network 23 controlled. 24

To d istinguish b etween a P MIP i nstance managing t he R3 mobility f or a s ingle u ser a nd t he f unctional e ntity 25 combining all these logical instances a new definition is introduced: 26

1. PMIP Mobility Manager: Functional entity managing multiple PMIP clients 27

2. PMIP client: Logical entity managing R3 Mobility for a single user/MS 28

In other words a ‘PMIP Mobility Manager’ = Σ ‘PMIP clients’. 29

Any R3 mobility session or PMIP client is uniquely identified by the user’s NAI. The NAI used for R3 Mobility can 30 be the same as the one used for access authentication. 31


Page - 160


IP

802.16CS

802.16e

802.16CS

802.16e

DP Fn

L2

DP Fn

L2

MIP

L2

IP

MIPL2

HoA@ payload BS@+Tunnel id HoA@ payload HoA@ payloadCoA@

MIP TunnelIntra - ASN Data path

MIP Foreign Agent

HoA@ payload

MIP Home AgentBSMS

CSNR3ASNR1

HoA@

1

Figure 7-68 - Proxy MIP Data Plane (Example) 2

AAA-Server

MIPL2

MIPL2

Authenticator

PMIP mobiltymanager

R3

MIP Home AgentMIP Foreign Agent

ASN CSN

3

Figure 7-69 - Proxy MIP Control Plane 4

In t he Proxy M IP s olution, t he I P ne twork a spects o f t he C SN Anchored M obility M anagement ha ndovers a re 5 transparent to the MS. The MIP registration to set up or update the MS’s forwarding path on the HA is performed by 6 the proxy-MIP client on behalf of the MS. The MIP related information required to perform MIP registrations to the 7 HA a re r etrieved via t he AAA messages e xchanged during the a uthentication phase. T his i nformation consists o f 8 Home Agent address, and the security information to generate the MN-HA authentication extension and either the 9 DHCP server address or HoA address. 10

7.8.1.8.1 Proxy-MIP FA Considerations 11 Additionally, in applicable distributed ASN configurations, the alternative PMIP redirection procedure as described 12 in Section 7.8.1.8.5 MAY be used. 13

As illustrated in Figure 7-69 the Foreign Agent behavior for proxy-MIP differs slightly from RFC3344 in that the 14 destination IP addresses for the control and data plane are different. 15

In the IETF MIP model the MIP client resides on the host and is the termination point for both the MIP signaling 16 and user traffic. In PMIP approach user data is sent to the MS over the corresponding R6 or R4 data path, MIP 17 signaling needs to be directed to a PMIP client within the PMIP mobility manager. 18

To achieve this goal, odd-numbered MN-HA SPI is used as an indication of PMIP usage. 19


Page - 161


Messages originated by the PMIP mobility manager will set the IP packet source address to the address of the PMIP 1 mobility manager. 2

MIP R egistration R eply will b e r eturned t o t he P MIP mobility manager i nstead o f t he M S b y F A. T he P MIP 3 mobility manager address is not directly linked to an MS’s R3 mobility session and can be changed at any t ime 4 independently of an ongoing R3 mobility session. 5

7.8.1.8.2 DHCP server/proxy consideration 6 There are two DHCP server/proxy deployments options for CSN anchored mobility in this Release: 7

1) DHCP proxy: There is DHCP proxy in the ASN acting as DHCP server to manage DHCP exchange with 8 MS. There is no DHCP messages cross R3. 9

2) DHCP relay: There is DHCP relay in the ASN to forward the DHCP messages between the DHCP server 10 in the CSN and MS. There are DHCP message cross R3. 11

NOTE: The DHCP Proxy is a DHCP Server from the perspective of the MS. 12

7.8.1.8.3 Proxy-MIP Connection Setup Phase 13 After successful access level authentication the R3 mobility connection setup takes place. 14

During R3 mobility connection-setup following actions are performed: 15

• Location of the Home-Agent is determined based on inter operator policies. 16

• MS PoA assignment. 17

• MS IP host configuration. 18

• MIP registration. 19

• R3 mobility authentication between MN and HA. 20

The signaling flow describing the connection setup phase for the Proxy-MIP using DHCP Relay option described in 21 [54]. 22

7.8.1.8.3.1 Backend IP Address Assignment Options 23 In the proxy-MIP solution a DHCP request is sent to the ASN network to retrieve the HoA address and IP host 24 configuration parameters. 25

Between the ASN and CSN network following options are available: 26

• DHCP relay: The DHCP relay in the ASN manages the DHCP exchange with the DHCP server in the 27 CSN. The DHCP server address is retrieved during access authentication. 28

• AAA based HoA assignment: IP host information and HoA address can be retrieved from the CSN as part of 29 the access authentication AAA exchange. In this case the ASN will host a DHCP proxy and return the 30 complete IP configuration to the MS. 31

• MIP: MIP exchange can be used by the PMIP client to retrieve the MS HoA address. For the MS host 32 configuration the PMIP client SHALL use normal Vendor/Organization Specific extensions [33] in the 33 MIP registration request. In that case, Mobile IP registration exchanges are triggered by DHCP proxy after 34 DHCP discovery is received, DHCP proxy will not send DHCP offer until MIP registration is complete. 35 After getting HoA from HA through the MIP registration progress, the PMIP client sends the HoA to the 36 DHCP proxy which will act as a server in the forthcoming DHCP exchanges. 37

In the AAA scheme the IP address of the MS is available in the ASN network prior to the IP connection or radio 38 connection establishment. In case of network-initiated connections, this information can be used to configure the SF 39 classifiers directly with the correct IP address information, avoiding address spoofing or bootstrapping procedures. 40


Page - 162


7.8.1.8.4 Proxy-MIP Session Renewal 1 To update session state in the network and allow context release in case of SS/MS or network failure both the MIP 2 context and the DHCP session state have to be renewed. 3

In a Proxy MIP approach the MIP context renewal is handled completely by the network. As MIP re-registrations do 4 not generate overhead o ver t he air interface o r i nterfere with SS/MSs going into sleep mode small refresh timer 5 values can be chosen. 6

DHCP renewals are initiated by the MS. 7

7.8.1.8.4.1 DHCP Relay 8 Please refer to [54] for more details. 9

7.8.1.8.5 Proxy-MIP CSN Anchored Mobility Management Handovers 10 The following signaling flow describes the CSN Anchored Mobility Management based on MS mobility event. In 11 the Proxy MIP approach handovers are initiated by the Proxy-MIP client. 12

7.8.1.8.5.1 CSN Anchored Mobility Management Triggered by MS Mobility 13

MS ASNa(FA1)

ASNb(FA2)

ASNc(PMIP) HA

8. Anchor_DPF_HO_Rsp(success)

7. FA_Register_Rsp(RRP)

6. RRP

5. RRQ

4. FA_Register_Req(RRQ MIPkeys)

3. Anchor_DPF_Relocate_Req(FA1-CoA, FA2-CoA)

2. Anchor_DPF_HO_Req(Authenticator ID, FA1-CoA,

R3MM)

1. Anchor_DPF_HO_Trigger

14

Figure 7-70 - MS Mobility Event Triggering a Network Initiated R3 Re-anchoring (PMIP) 15

STEP 1 16

If the target ASNb initiates the FA relocation negotiation, it sends an Anchor_DPF_HO_Trigger message to the 17 anchor DPF in ASNa. If ASNa agrees with the FA relocation, it proceeds to Step2. 18

If the source ASNa initiates the FA relocation procedure, the call flow starts from Step2. 19

STEP 2 20

ASNa sends an Anchor_DPF_HO_Req message to the DPF in ASNb. The message contains Authenticator ID, the 21 current FA-CoA address and the DHCP context information for the MS. 22

STEP 3 23

Target ASN for FA relocation sends an Anchor_DPF_Relocate_Req message to the PMIP Client. This message 24 relays some information about target ASN that is necessary in order to construct and send the MIP RRQ message in 25


Page - 163


step4. The message contains CoA for the target FA, and target FA address if it is different than the CoA. In addition 1 to target FA-CoA, current FA-CoA is included in the message. 2

STEP 4 3

The PMIP Client verifies that the current FA-CoA indeed matches the FA on its record, and starts the MIP 4 registration with the target FA by sending FA_Register_Req message. This message contains a fully formed RRQ 5 according to RFC3344, with CoA field in the RRQ set to the CoA of the Target FA which is received in 6 Anchor_DPF_Relocate_Req message in step3. The source address of the RRQ is that of the MS and the destination 7 address the CoA or the FA if FA address is different from CoA. In addition, FA_Register_Req message contains the 8 FA-HA MIP key if this key is used. This message is sent to the Target ASN, whose address was identified as the 9 source address of the Anchor_DPF_Relocate_Req message in step3. 10

STEP 5 11

The target FA relays the RRQ to the HA. 12

STEP 6 13

The HA responds with the RRP. 14

STEP 7 15

The target ASN relays the MIP RRP encapsulated in an FA_Register_Rsp message to the PMIP Client. The PMIP 16 Client updates the FA in its record. 17

STEP 8 18

The target ASN also replies to the source ASNa with an Anchor_DPF_HO_Rsp message indicating a successful FA 19 relocation. The source ASNa can then remove the mobility binding, DHCP context information and the R4 data path 20 towards the ASNb. 21

7.8.1.8.6 Proxy-MIP Session Termination 22 In case of MS session termination the corresponding R3 mobility session has to be released. 23

An MS can either gracefully terminate its ongoing IP connection (e.g., by sending a DHCP release) or a session 24 termination can be caused by an error condition. 25

Typical error conditions could be, MS out of coverage, low battery, system error, etc. 26

Criteria for initiating a R3 session release are not covered in this section. 27

The Proxy MIP client will receive a s ession release trigger from an ASN functional entity, or the MIP Revocation 28 from HA. 29

The R3 Mobility session is released by sending a MIP registration with a lifetime of zero. 30


Page - 164


FAMS Authenticator+ PMIP client H-AAAHAASN Funtional

Entity

1) Sessionrelease trigger

R3_Session_Release.Request

2) MIP Registration Request(lifetime = 0) 3) MIP Registration Request

(lifetime = 0)

5) MIP Registration Reply4) MIP Registration Reply

6) R3_Session_Release.Response

7) R3_Session_Release.Confirm

1

Figure 7-71 - R3 Session Release 2

For charging and accounting purposes the HA MAY optionally send an AAA Accounting message to the MS’s H-3 AAA server. 4

Note that R6 or R4 session termination is not covered by the signaling flow illustrated in Figure 7-71. 5

After receiving the R3_Session_Release.Request message from the ASN Functional Entity, the PMIP client SHALL 6 release the tunnel associated with the MS. In addition, the PMIP client SHALL notify the ASN functional entity to 7 update the MS session context. 8

If t here ar e more t han o ne session identifiers contained i n t he R3_Session_Release.Request m essage, t he P MIP 9 client SHALL repeat the same steps for each session contained in the R3_Session_Release.Request. 10

7.8.1.9 Client MIP R3 Mobility Management 11 This section describes requirements and procedures for the CMIP R3 mobility management. 12

Figure 7-72 provides an example of an MS with multiple wireless and wired access options. The depicted stack can 13 support handoff across different access technologies. In the following discussion we only address R3 mobility for 14 IEEE 802.16 access links. For release one, Inter-technology handovers are outside the scope of R3 mobility. 15


Page - 165


MIP Client

MIP Client Component

3G Modem WiMAX Ethernet Dial-up WLAN

NIC Level

Device Driver

TCP/IP Stack

Operating Sys

1

Figure 7-72 - MS with Mobile IP Stack and Multiple Access Options 2

At th e time o f the initial M IP session e stablishment, when new R 6 tunnel is e stablished b etween t he D ata P ath 3 Function at the ASN-GW and the Data Path Function in the new target BS, the MIP client receives a mobility trigger 4 in the form of new MIP advertisement from the FA. 5

The FA is located at the boundary of the ASN and the CSN and terminates the R3 Reference Point within the ASN. 6 The MIP client is a single entity that supports R3 mobility for a single user and is located above the 802.16 drivers 7 and can be an integral part of the OS stack. Such client typically includes multiple components (modules) that MAY 8 span various stack elements as shown above. 9

IP

802.16CS

802.16e

802.16CS

802.16e

DP Fn

L2

DP Fn

L2

MIP

L2

MIP

L2

IP

HoA@ payload HoA@ payload HoA@ payload HoA@ payloadBS@+Tunnel id CoA@

BSMSMIP Client

HoA @

FA HA

Intra-ASN Data Path MIP tunnel

R3CSNASN

R1

10

Figure 7-73 - Mobile IP Data Plane (Example) 11


Page - 166


MIP

UDP

IP

CS

802.16 MAC

802.16 PHY

MS

CS

802.16 MAC

802.16 PHY

L2 / Intra-ASN Data

Path

PHY

BS

MIP

UDP

IP

L2

PHY

CSN/HA

MIP

UDP

IP

PHY

MIP

IP

L2

PHY

L2 / Intra-ASN Data

Path

FA 1

Figure 7-74 - Mobile IP Control Plane 2

The M IP cl ient i n t he M S p articipates i n t he message ex changes r equired t o p erform inter-ASN a nd in ter-NAP 3 mobility. T he M IP c lient s upports d ynamic a ddress a ssignment a nd d ynamic H A a llocation. T o s upport 4 unambiguous detection of the MS’ capabilities and determination of use of CMIP versus PMIP for Ipv4, the use of 5 co-located CoA mode with CMIP4 (when used only with the WiMAX interface), SHALL NOT be supported in this 6 specification. When the MIP client is involved in inter-technology handoffs, the use of Collocated CoAs (CCoA) is 7 allowed in association with access interfaces different than IEEE Std 802.16. 8

7.8.1.9.1 Client-MIP Connection Setup Phase 9 Upon successful access level authentication, the MS obtains the AAA-Key/MSK and EMSK. When HA address is 10 not assigned, the MS can obtain the HA address as part of the Mobile IP registration messages exchange. 11

The following signaling flow describes the connection setup phase: 12


Page - 167


MSCMIP BS Authenticator FA HA HAAA

Authorization Access1) access authentication

Access authentication (AAA-Key, HA@)Access authentication

(AAA-Key)

7) AAA Response

6) AAA Request

5) MIP RReq (NAI, HoA, CoA)

8) MIP RResp (NAI, HoA, CoA)

R3 MIP tunnel

9) MIP RRep (HoA)

4) MIP RReq (NAI, HoA, CoA)

3) MIP Adv (CoA)

Binding of MS flow to Intra-ASN Data Path

1

Figure 7-75 - Connection Setup 2

1) Access Authentication: During access level authentication the AAA authentication key is retrieved from the 3 AAA access authentication message exchanged with the MS home AAA server. 4

2) A trigger is generated when binding of MS or MS flow with intra-ASN Data Path is established. 5

3) When new intra-ASN Data Path is established configurable number of advertisements is sent to the MS. 6

4-5) The MIP registration is performed by the client and forward to the HA. MS using Mobile IP connectivity 7 will not issue DHCP requests and will only use MIP signaling to obtain its home address. 8

6) HA sends AAA request message to Home AAA. 9

7) Upon receipt of an AAA request message from a HA containing the MN-HA attribute, the AAA server 10 SHALL send an AAA response message indicating success and containing the encrypted MN-HA shared 11 key. If registration request included dynamic HA assignment and IP host configuration the HA address and 12 the IP configuration will be respectively returned by the AAA as well. 13

8) The HA forwards the Registration Reply to the FA. 14

9) MIP Registration Reply is forwarded to the MS containing the MS home address. 15

IP H ost c onfiguration: The M S M AY use e xtensions d efined i n d raft-bharatia-mip4-gen-ext-01.txt i n t he M IP 16 Registration Reply to obtain its IP host configuration. 17

7.8.1.9.2 Client MIP Session Renewal 18 To update session s tate i n the network and al low a context release in ca se o f SS/MS or network failure the MIP 19 context SHALL be renewed. The client sends Mobile IP re-registration messages to the FA according to [43]. Upon 20 receiving the re-registration request the HA will reset the MIP session timer. Authentication is based on the prior 21 keys obtained during initial authentication and as such do not require a synchronization with the user authentication 22 server. The following depicts the message flow. If MN-FA is used, the challenge used by the MS for re-registration 23 SHOULD b e t he o ne l ast s ent b y t he prior M IP re gistration/re-registration r esponse. On r e-registration, t he F A 24


Page - 168


MAY co mmunicate u ser F AC au thentication i nformation t o t he H ome AAA Server. The f requency o f this r e-1 authentication and re-authorization is configurable. 2

MS FA HA

1) MIP Re-Registration Request(NAI, MN_HA, FA)

4) MIP Re-Registration Reply

2) MIP Re-Registration Request

3) MIP Re-Registration Reply

3

Figure 7-76 - Session Renewal, MIP Re-Registration 4

7.8.1.9.3 Client MIP CSN Anchored Mobility Management 5 As previously mentioned, MIP R3 mobility handovers are always network initiated. Even when the mobile initiates 6 the handover to a new BS and FA, the R3 mobility is a result of a network event that strives to minimize impact on 7 real time traffic when migration R3 from anchored to target FA. The R3 mobility trigger is typically a delayed event 8 to the FA re-anchoring procedure described in 7.8.1.10. 9

7.8.1.9.4 Foreign Agent Advertisement 10 When a n ew M S o r a s ervice f low within M S i s in itially b ound to a n in tra-ASN D ata P ath, t he F A b egins t he 11 transmission of configurable number of Agent Advertisements to the MS. O nce the configurable number of Agent 12 Advertisement is sent, the F A w ill n ot send m ore A dvertisement. Only w hen th e MS sends A gent Solicitation 13 message the FA will respond with an Agent Advertisement. When the first MIP Registration Request is received by 14 the FA, it SHALL cease sending Agent Advertisements even if the number sent is less than the configurable number 15 of Agent Advertisements. 16

In o rder to m inimize A gent A dvertisement s ent o ver th e a ir, th e F A S HOULD not s end u nsolicited A gent 17 Advertisements to the MS to refresh the advertisement lifetime. The MS MAY send Agent Solicitation when the FA 18 advertisement lifetime expires or about to expire. The advertisement lifetime is a configurable value and can be set 19 to the maximum value of 9000 seconds (the maximum ICMP advertisement lifetime). 20

7.8.1.9.5 Client-MIP Session Termination 21 In case an MS active IP session has to be terminated, both the MAC state as well as intra-ASN Data Paths between 22 the FA and the HA has to be gracefully removed. 23

The four termination scenarios are as follows: 24

(1) An MS initiated graceful termination: a session is gracefully terminated by sending a MIP Registration Request 25 message with lifetime = 0 . This termination is triggered either by the user or MS being in an error conditions 26 such as low battery power, etc. 27

(2) ASN in itiated g raceful te rmination: T he c onditions for A SN in itiated te rmination M AY b e s ome e rror 28 conditions with r espect t o t he MS s uch as t he M S b eing i dentified as a r ogue M S with s ecurity v iolations, 29 planned maintenance, et c. T his scenario i s d epicted i n F igure 7 -73. A s ession i s gracefully t erminated b y 30 sending an R3_Session_Release.Request message from an ASN Functional entity like the intra-ASN Handover 31 function. A fter r eceiving t he R 3_Session_Release.Request m essage f rom a n ASN F unctional en tity, t he F A 32 SHALL trigger registration revocation procedure with HA to terminate binding as per RFC 3543. Based on the 33 local policy, FA may set the I bit in Revocation Request message to consult with HA if the MS will be informed 34 of the revocation. If HA supports such revocation option, it will set I bit in the Revocation Acknowledgement 35 message. After r eceiving t he R evocation Acknowledgement message with I b it s et, F A will send a n Agent 36 Advertisement to the MS with sequence field set to 0. 37


Page - 169


MS FA ASN FunctionalEntity HA

1) Session releasetrigger

1a) R3_Session_Release.Req

1b) R3_Session_Release.Confirm

2) MIP Revocation request

3) MIP Revocation Acknowledgement

5) R3_Session_Release.Response

Clear MIP Session

4) Mobility Agent Advertisement

1

Figure 7-77 - ASN Initiated Graceful Termination 2

(3) HA initiated graceful termination: This scenario is depicted in Figure 7-74. A session is gracefully terminated 3 when HA triggers registration revocation with FA as per RFC 3543. FA sends the R3_Session_Release.Request 4 to ASN Functional to notify termination of mobility binding. MS may be informed depending on if the I bit is 5 set in Revocation message. 6

MS FA ASN FunctionalEntity HA

2) MIP Revocation request

3) MIP Revocation Acknowledgment

1) Session releasetrigger

4) Mobility Agent Advertisement

Session termination

7

Figure 7-78 - HA Initiated Graceful Termination 8


Page - 170


(4) MS loss of carrier unconventionally t ermination: the s cenario w hen the BS detects t he MS i s loss of car rier 1 unconventionally, the BS SHALL inform ASN Function Entity by sending an Path_Dereg_Req with operation 2 reason as “ MS l oss o f car rier”. Then, i f t he S FA an d D ata P ath F unction o f ASN F unction E ntity make a 3 decision to release R3 and the related R6 or R4 resource, it SHALL inform the FA to release the HA to unbind 4 the P oA ad dress o f t he M S b y sending P ath_Dereg_Req, t hus t he session i s t erminated. T his s cenario i s 5 depicted in Figure 7-75. At the same time, in this scenario, ASN Function entity can release ASN resource for 6 the MS, such as intra-ASN data path etc. 7

MSFA

+Data pathFunction

SFA+ASNFunction Entity

SFM+Data path Function HA

3) Session Release Trigger

1)Detecting MSS loss of carrier

2) Path_Dereg_Req(MS ID, loss of carrier)

4) Path_Dereg_Req(MS ID)

5) Registration Revocation

6) Registration Revocation Acknowledgement

7) Path_Dereg_Rsp(MS ID)

8) Path_Dereg_Rsp(MS ID, loss of carrier)

9) Path De-Registration Acknowledge(MS ID, loss of carrier)

8

Figure 7-79 - MS Loss of Carrier Unconventionally Termination 9

7.8.1.10 CSN Anchored Mobility Management to ASN-Anchored Mobility Management 10 Relationship 11

This section describes a possible link between ASN-anchored mobility and CSN Anchored Mobility Management 12 and is meant as informational. Actual implementations can differ from the option described below. 13

Figure 7-80 illustrates the t wo major h andover t ypes d escribed ab ove f rom b oth an architecture an d f unctional 14 perspective. T he t op o f t he F igure s hows ASN1 an choring R3 an d f orwarding b earer t raffic t o ASN2 o ver R 4 15 (labeled before) followed by an R3 relocation message that relocates R3 bearer traffic from ASN1 to ASN2 (labeled 16 after). The bottom p art s hows a co mbined CSN -anchored mobility handover e vents where R3 is relocated f rom 17 ASN1 t o ASN2 without a pr ior A SN anchoring. C ombined C SN/ASN-anchored m obility h andovers is n ormally 18 triggered by an MS mobility event like running into coverage of a new Base Station, although these handover can 19


Page - 171


also be a result of a resource optimization decision. The dotted line represent the initial state before a handover, the 1 solid line depicts the data path after a combined R3/R6 handover. 2

The top part of Figure 7-80 illustrates a typical RRM based handover that results in both an ASN Anchored Mobility 3 where traffic is forward from ASN1 to ASN2 followed by a CSN-anchored mobility handover where R3 is relocated 4 from ASN1 to ASN2. 5

In case of an RRM based handovers the R3 handover request is never sent directly from the RRM controller to the 6 mobility manager but will be passed through the ASN Handover Function. This approach facilitates synchronization 7 between t he d ifferent ASN functional e lements. Additionally it makes t he R 3 mobility tr ansparent to t he RRM 8 management. 9


Page - 172


ResourceOptima\izationR3MobilityHandover

after ASNAnchored Mobility

ServingFA

FA

NetworkArchitecture

BS

BS

FA HA

FA

FAPMIPClient

Intra-ASN Fun.

BSMS/SS

After R3Relocation

Before R3Relocation

ASN2

ASN1R3

R3 Relocate

MSMobilityEventR3relocation

InterASNHandover

R3

Intra-ASN Fun. R3 Relocate

PMIPClient FA

MS/SS BS

BS

BS

HAFAASN1

FAASN2

NetworkArchitecture

After R3Relocation

Before R3Relocation

TargetFA

Data PathFunction

R3

R3

R4

MIP Req

MIP Req

1

Figure 7-80 - R3MM to Intra-ASN Mobility Relationship 2

From ASN-anchored mobility management perspective, there are two scenarios exist where an R3 handover can be 3 initiated. T he first s cenario i s d uring a n ASN-anchored mobility h andover e vent, e .g., upon r eceiving a n H O-4 indication message a t t he ASN F unctional e ntity. T he s econd s cenario ( which is p referred) is t o in itiate a n R 3 5 handover after the ASN-anchored mobility handover has been successfully executed, e.g. when the ASN Functional 6 Entity r eceives a n Anchor_DPF_Relocate_Req. Triggering a n R 3 ha ndover a fter t he A SN-anchored m obility 7 handover has b een fully p rocessed av oids s cenarios where an R 3 h andover n eeds t o b e can celled an d t he o ld 8 connection is reestablished due to unsuccessful ASN-anchored mobility. 9


Page - 173


Applying ASN data forwarding prior and during the time it takes to complete an R3 handover minimizes packet loss 1 and handover interruption time. After the new R3 path has been established the PMIP mobility manager will notify 2 the ASN Functional Entity by sending an ‘Anchor_DPF_Relocate_Rsp’ message. 3

The Anchor_DPF_Relocate_Rsp message can be used b y the ASN Functional Entity to te rminate i nter-ASN data 4 forwarding between the old and new ASN. 5

7.8.1.11 CSN Anchored Mobility Management Trigger Primitives 6 Table 7-2 lists t he messages i nvolved i n R3 mobility. N ote t hat t hese messages M AY b e ex changed b etween 7 functional entities within a single ASN, or between functional entities in different ASNs. 8

Table 7-2 - R3MM Mobility Management Primitives “for information only, the binding facts are 9 defined in the Stage3 Specification” 10

Primitives From => To Message Content Applicability CMIP/PMIP

HoA_Address DHCP Proxy => PMIP Client MSID, HoA @, Transaction ID PMIP

HoA_Address.Ack PMIP Client => DHCP Proxy MSID, Status, [error code], Transaction ID, Status

PMIP

DHCP_Gating.Release PMIP Client => DHCP Proxy MSID, Transaction ID PMIP

R3_Session_Release.Request ASN-Fn => PMIP Client

ASN-Fn => FA

MSID, list of (status (Successful, Failed), [Error Code]) attributes, Transaction ID

PMIP

CMIP

R3_Session_Release.Response PMIP Client => ASN-Fn

FA => ASN-Fn

MSID, list of (MIP session ID, status (Successful, Failed), [Error Code]) attributes, Transaction ID

PMIP

CMIP

R3_Mobility_Context DHCP Proxy => ASN-Fn

FA => ASN-Fn

MSID, R3 Mobility Mode, Transaction ID

PMIP

CMIP

R3_Mobility_Context.Ack ASN-Fn => DHCP Proxy

ASN-Fn => FA

MSID, Transaction ID, Status (Successful, Failed), [Error Code]

PMIP

CMIP

Anchor_DPF_Relocate_Req ASN-Fn => PMIP Client

ASN-Fn => Target FA

MSID, Target FA, Transaction ID PMIP

CMIP

R3_Relocate. Confirm PMIP Client => ASN-Fn

FA => ASN-Fn

MSID, Transaction ID PMIP

CMIP

Anchor_DPF_Relocate_Rsp PMIP Client => ASN-Fn

Target FA => ASN-Fn

MSID, Transaction ID PMIP

CMIP

7.8.1.11.1 HoA_Address 11 The HoA_Address message provides the HoA address retrieved from the CSN to the PMIP client. 12

As described in the session setup paragraph the HoA address can be provided during the access authentication as 13 part of the AAA exchange or can be retrieved for a DHCP server in the CSN network. 14

• MSID: Identifies the MS for which an R3 handover is requested. 15


Page - 174


• HoA Address: Home address of the MS. 1

• Transaction ID: Random generated number to correlate request and response. The Transaction ID together 2 with the MS uniquely identifies a request 3

7.8.1.11.2 HoA_Address.Ack 4 A HoA_Address.Ack is send by the PMIP Client upon successfully receiving the HoA_Address message. 5

• MS ID: Identifies the MS for which an R3 handover is requested. 6

• Transaction ID: Correlates the replies with the correct request. To match Replies with Requests the 7 Transaction ID in the reply SHALL match the Transaction ID in the Request. 8

• Status: Indicates whether or not the HoA_Address message was successful received. 9

o In cas e o f failure a n ad ditional er ror co de i dentifying t he r eason o f failure can b e a dded ( e.g., 10 unknown MS ID). 11

7.8.1.11.3 R3_Session_Release.Request 12 An R3_Session_Release.Request will terminate the R3 MIP session for a specific MS. 13


• Transaction ID: Random generated number to correlate request and response. The Transaction ID together 15 with the MS uniquely identifies a request. 16

7.8.1.11.4 R3_Session_Release.Response 17 The R3_Session_Release.Response message indicates either a successful or failed R3 handover event in response of 18 an R3_Release.Request. 19


• List of (Status (Successful, Failed), [Error Code]) attributes: Optionally list the MIP session to be released 21 event result. 22

• Status: Indicates whether or not the R3 handover was successful. 23

o In case of failure an additional error code identifying the reason of failure can be added. 24

• Transaction ID: Correlates the replies with the correct request. To match Replies with Requests the 25 Transaction ID in the response SHALL match the Transaction ID in the Request. 26

7.8.1.11.5 R3_Mobility_Context 27 The R3_Mobility_Context is used to inform the ASN Functional Entity whether the MS is in Proxy-MIP or CMIP 28 mode. Additionally s ome R3 c ontext i nformation c an be added. This i nformation is used b y t he ASN Function 29 Entities to determine the correct moment in time to trigger an R3 handover request plus the correct destination of the 30 message (e.g., FA or PMIP mobility manager). 31


• R3 Mobility Mode: Indicates the R3 mobility the MS is using. The field can take two values, 33 eitherCMIP4, CMIP6 or PMIP4. 34

• Transaction ID: Random generated number to correlate request and response. The Transaction ID together 35 with the MSID uniquely identifies a request. 36

7.8.1.11.6 R3_Mobility_Context.Ack 37 An R3_Mobility_Context.Ack i s s end b y t he ASN Functional E ntity upon s uccessfully r eceiving t he 38 R3_Mobility_Context message. 39



Page - 175


• Transaction ID: Correlates the replies with the correct request. To match Replies with Requests the 1 Transaction ID in the response SHALL match the Transaction ID in the Request. 2

• Status: Indicates whether or not the R3_Mobility_Context message was successful received. 3 In case of failure an additional error code identifying the reason of failure can be added (e.g., unknown 4 MSID). 5

7.8.1.11.7 Anchor_DPF_Relocate_Req 6 R3 Anchor_DPF_Relocate_Reqs a re u sed t o t rigger a n R3 h andover. R 3 Anchor_DPF_Relocate_Reqs can b e 7 triggered b y t he r esource m anagement function o r o ther ne twork e ntities. Upon r eceiving a n R 3 8 Anchor_DPF_Relocate_Req, the ASN Functional Entity will send a R3_Relocation.Request to the ASN Functional 9 Entity and start R3 handover procedure. 10

• MSID: identifies the MS for which an R3 relocate is requested. The MSID is based on the MS’s NAI. In 11 PMIP the MS identifies a specific PMIP client in the PMIP client. 12

• Target FA: Identifies the new R3 anchor point for the MS. In MIP terminology the Target FA address 13 corresponds to the FA’s CoA address. 14


7.8.1.11.8 R3_Relocate.Confirm 17 R3_Relocate C onfirm i s used to ack nowledge s uccessful r eceipt of t he R3 Anchor_DPF_Relocate_Req message. 18 The confirmation does not give any feedback on the actual processing or state of the R3 relocation. 19

• MSID: Identifies the MS for which an R3 relocate is requested. The MSID is based on the MS’s NAI. In 20 PMIP the MS identifies a specific PMIP client in the PMIP client. 21


7.8.1.11.9 Anchor_DPF_Relocate_Rsp 24 The R3 Anchor_DPF_Relocate_Rsp message indicates either a successful or failed R3 relocate event in response of 25 an R3 Anchor_DPF_Relocate_Req. 26

• MSID: Identifies the MS for which an R3 relocate is requested. The MSID is based on the MS’s NAI. In 27 PMIP the MS identifies a specific PMIP client in the PMIP mobility manager. 28

• Target FA: Identifies the new R3 anchor point for the MS. In MIP terminology the Target FA address 29 corresponds to the FA’s CoA address. 30


7.8.1.12 Proxy-MIP and Client MIP Coexistence 33 R3 mobility can be provided based on two mechanisms: 34

• Client MIP solution based on a MIP client in the MS. 35

• Proxy MIP solution based on MIP client in the network. 36

Both solutions are based on a different network and SS/MS behavior and therefore require special consideration to 37 support both on the same network. Which R3 mobility scheme is used depends on a number of factors like SS/MS 38 type, MIP client availability, inter-technology handovers support, type of operator, roaming considerations, etc. 39

In order to be able to accommodate for any type of SS/MS and inbound roamer a network SHOULD ideally be able 40 to support both the CMIP and PMIP R3 mobility schemes. 41


Page - 176


With both PMIP and CMIP being mandatory from network point o f v iew several scenarios can be identified, the 1 table below gives a short overview of the different possibilities. Table 7-3 only covers R3 mobility, fallback options 2 to nomadic access based on network capabilities or operator policies are not covered. 3

Table 7-3 - R3MM coexistence scenarios 4

MS support Network Support Decision

MIP CMIP CMIP

Simple-IP PMIP PMIP

MIP CMIP + PMIP CMIP

Simple IP CMIP + PMIP PMIP

MIP PMIP Not Applicable

Simple-IP CMIP Not Applicable

The Coexistence solution focuses on the following points: 5

• MS capability discovery. A MS can be categorized as either a simple IP SS/MS or a MIP enabled MS. A 6 simple IP SS/MS can be any IP SS/MS using DHCP for IP address assignment. 7

• Supported network mobility schemes discovery. Based on some of the arguments listed above an 8 operator might decide to only support PMIP or CMIP or both schemes. 9

• R3 mobility scheme selection. Once both the SS/MS and network capabilities are known the correct R3 10 mobility scheme needs to be activated. 11

7.8.1.13 Coexistence for Networks Supporting Both CMIP and PMIP 12 This specific coexistence scenario deals with networks that are able to support both s imple IP SS/MSs as well as 13 Mobile-IP enabled MSs. 14

Which scheme the network applies will depend on the SS/MS capabilities and can additionally be imposed by the 15 Home-NSP based on the knowledge of both the SS/MS capabilities and NAP mobility support. 16

If the Home NSP is unable to determine the SS/MS capabilities or the network supported R3 mobility schemes the 17 home AAA -server will p rovide b oth t he n ecessary P MIP and C MIP i nformation t o t he A SN d uring t he Access 18 Authentication phase. 19

Prior to an intra-ASN data path establishment the network is unaware of the MS capabilities, so immediately after 20 the data path between ASN-located FA and MS is established, the FA entity will send an FA advertisement to the 21 SS/MS over this newly established data path. If the SS/MS is MIP enabled it will perform a MIP registration using 22 the CoA advertised in the FA advertisement. 23

The MIP registration originated from the MS will force the network into CMIP mode. 24

A MS without MIP functionality (simple IP SS/MS) will discard the FA advertisement and send a DHCP request to 25 get an IP address. The DHCP request will trigger the PMIP Mobility Manager – HoA_Address message – to setup 26 an R3 session on behalf of the MS. 27

So f or n etworks supporting both C MIP a nd P MIP t he s election i s s traightforward a nd dr iven b y t he SS/MS. 28 Network capability discovery is based on MIP agent advertisement messages send just after connection setup. The 29 mobility scheme selection is determined by the ASN, based on the type of message received from the SS/MS and 30 can be either a DHCP request or a MIP registration request. 31

To avoid situations where due to loss of the FA advertisement message or unexpected delays a MIP client would go 32 into collocated CoA mode the MIP client needs to be configured such that collocated CoA mode is prevented for the 33


Page - 177


WiMAX® interface. In collocated CoA mode, the MIP cl ient will send a D HCP request to retrieve the co-located 1 care of address, this message will be wrongly interpreted by the network as a request to establish a PMIP session. 2

After initial R3 session setup the ASN network stores the current R3 Mobility mode the SS/MS is in. 3

The R 3 mobility mode n eeds to b e s tored a t the ASN F unctional E ntity. B ased o n t his in formation the AS N 4 Functional entity can determine the right moment and destination to send an R3 Relocation_Req to. Knowledge of 5 the R 3 mobility mode will a lso p revent u nnecessary a ir-overhead b y s uppressing F A a dvertisements af ter ev ery 6 handover in case of PMIP users. 7

For MIP enabled SS/MSs the R3 mobility tr igger will be send directly to the FA, for PMIP user the R3 mobility 8 trigger will be sent to the PMIP mobility manager. 9

7.8.1.14 R3 Mobility Session Authentication and Authorization 10

7.8.1.14.1 Proxy-MIP Security 11 The following section describes the elements of the PMIP security framework and their interaction to dynamically 12 establish a PMIP key to enable a Proxy Mobile IP client and Home Agent (HA) exchange authenticated registration 13 requests and response messages. 14

Authenticator

Proxy-MIP client

AAA

HAFAMS

Data Path

PMIP Authorization and Key Path

MIP Signaling Path

1

2

3

4

65

CSN

ASN

15

Figure 7-81 - PMIP Functional Elements 16

Figure 7-81 shows the function elements related to PMIP. During network entry the mobile node (MS) authenticates 17 to t he AAA via a n a uthenticator, us ing a n E AP a uthentication p rocess. At t he e nd o f t he e xchange, i f t he 18 authentication i s successful, the AAA server s ends an EAP s uccess a nd a n otification of au thorization for PMIP 19 process to the authenticator. At this point the Authenticator obtains the PMIP Key. The AAA server SHALL send 20 the SPI, lifetime and any other PMIP related information (such as HoA, HA IP address, and so on, if desired) along 21 with the authorization notification for PMIP. The lifetime of this key SHALL be the same as that of the MSK that is 22 generated a s a r esult o f s uccessful au thenticator. T he Authenticator S HALL share t he P MIP k ey an d r elated 23 information with the Proxy-MIP cl ient. The Proxy Mobile Node (PMN) MAY use this key for the l ifetime of the 24 key, i.e., additional registration requests MAY be generated using the same Proxy-MIP Client when the lifetime of 25 the registration expires or when the MS moves to a new subnet requiring a new registration. 26


Page - 178


PMN Authenticator FA HA AAA

1) Authentication Message

Has PMIPKey

2) Share [PMP key + Related info]

3) RRQ [MHAE derived using PMIP key]

6) RRP [MHAE derived using PMIP key]

RRQ [MHAE derived using PMIP key]

RRP [MHAE derived using PMIP key]

4) AAA Request

5) AAA Response[with PMIP key]

Additional RRQ/RRP mayhappen without contactingAAA server until lifetime ofPMIP key

1x) AAA Response

1a) AAA

1

Figure 7-82 - PMIP Key Generation and Transfer – Message Sequence 2

a) During network entry the mobile node (MS) authenticates to the AAA via the authenticator, using an EAP 3 authentication p rocess. T his MAY ta ke multiple steps a nd a t t he e nd o f s uccessful a uthentication th e 4 authenticator o btains th e P MIP K ey. N ote th at th e P MIP k ey t hat i s o btained b y t he authenticator is in 5 addition to the MSK that is provided by the AAA server as a result of EAP. 6

b) The PMN function obtains the key and related information from the authenticator function. 7

c) When the PMN generates a r egistration request (Registration Request) i t uses the PMIP key to create the 8 Mobile-Home Authentication E xtension ( MHAE) to a uthenticate t he r egistration r equest to th e H A. T he 9 PMN MAY include the NAI extension in the Registration Request 10

d) When a HA receives a r egistration request, if it does not have t he SPI/keys corresponding to the MN, it 11 queries the AAA server via an AAA Request. 12

e) The A AA server validates the r equest a nd s ends an AAA R esponse with t he M N-HA ke y ( PMIP ke y) 13 corresponding to the Proxy-MIP Client that is identified in the Request. After receiving the PMIP key, the 14 HA validates t he MHAE in Registration Request, and p rocesses the Registration Request and generates a 15 registration response with a valid authentication extension using the same MN-HA key. 16

Further exchanges of Registration Request and Registration Reply can happen without contacting the AAA server 17 until the expiration of the MN-HA key. 18


Page - 179


7.8.1.14.2 Client-MIP Security 1

7.8.1.14.2.1 Client MIP Authentication 2 For M obile IPv4 authentication, MN-HA a nd F A-HA authentication are mandatory to i mplement, M N-FA 3 authentication is optional to implement. MN-HA and MN-FA keys are derived from EAP EMSK. 4

7.8.1.14.2.2 AAA Support 5 During n etwork acces s a uthentication t he AAA s erver b ootstraps t he H A I P ad dress t o b e u sed f or M IP t o t he 6 Access Network. At the same time, it bootstraps the FA-RK from which an MN-FA can be computed as well as the 7 HA-RK from which an FA-HA can be computed. The HA IP address can be in the home CSN or visited CSN. For 8 Mobile IPv4, when the FA receives the MIP Registration Request it forwards the MIP Registration Request to the 9 HA-IP address bootstrapped during network access authentication. 10

The MIP Registration Request contains the MN-HA Authentication Extension signed using the MN-HA key derived 11 at the mobile from the EMSK. When the HA receives the MIP Registration Request it needs to obtain the MN-HA 12 key to va lidate the MN-HA Authentication Extension and an HA-RK key ( if i t doesn’t have one) to compute the 13 FA-HA Authentication Extension. T he HA sends an AAA request packet to the home AAA server. T his access 14 request is routed to the home AAA server using the NAI contained in the MIP NAI extension. 15

The home AAA server uses the NAI to lookup the user session and computes the MN-HA and sends it to the HA in 16 an AAA accept message. 17

7.8.1.15 Layer 2 DHCP Relay Option 18 WiMAX® networks supporting Ethernet services MAY provide support for a layer 2 DHCP relay agent. A layer 2 19 DHCP relay agent is commonly used in some widely deployed types of networks like xDSL, and such networks are 20 likely to interact with WiMAX network supporting Ethernet services. When WiMAX ASN provides layer 2 DHCP 21 relay functionality, it SHALL be conformant with layer 2 DCHP relay as described in [87]. A layer 2 DHCP relay 22 agent intercepts DHCP messages sent from MS and adds a relay agent suboption before relaying the message to the 23 server. In a downlink direction, layer 2 DHCP relay intercepts DHCP messages from the DHCP server and removes 24 the relay agent suboption before relaying the message to the MS. The layer 2 DHCP relay d iffers from a r egular 25 DHPC relay in following aspects: 26

• It doesn’t set the giaddr field when relaying a message to the DHCP server 27 • It d oesn’t c hange t he i ntercepted p acket i n a ny way e xcept f or a dding a r elay a gent s uboption. I n 28

particular, a broadcast DHCP packet will not be converted to a unicast packet before it is relayed to the 29 DHCP s erver. I nstead, a l ayer 2 D HCP r elay d evice will forward s uch p ackets a s b roadcast o n i ts 30 upstream interface. 31

• It doesn’t have to be configured with the IP address of the DHCP server 32 After successful access level authentication the IP connectivity setup takes place. In WiMAX networks supporting 33 Ethernet services, the layer 2 DHCP relay agent is located in the ASN GW. The following signaling flow describes 34 the connection setup phase using the layer 2 DHCP relay. 35

The home AAA server SHALL be able to decide to turn the layer 2 DHCP mode on or off for a particular MS 36 during the MS authentication procedure. In the Access-Request message the ASN/ASN GW SHALL indicate its 37 support f or l ayer 2 D HCP r elay function in t he WiMAX ASN S ervice Capabilities a ttribute. I f th e M S p rofile 38 indicates that the layer 2 DHCP mode is the preferred mode of operation for the MS being authenticated and if the 39 ASN indicated that it supports layer 2 DHCP relay function, then the home AAA server MAY request the ASN to 40 run i n l ayer 2 D HCP r elay mode b y setting t he Authorized N etwork s ervice at tribute i n t he Access-Response 41 message to the appropriate value. 42

When l ayer 2 D HCP r elay i s act ivated f or a p articular M S, D HCP O ffer a nd D HCP Ack messages ar e f iltered 43 upstream, i.e. DHCP Offer and DHCP Ack messages send by the MS are discarded. 44

When r elaying a message to the DHCP server (or to an upstream layer 3 DHCP relay), the layer 2 DHCP r elay 45 SHALL s et t he Circuit I D a nd R emote I D s uboptions [ RFC 30 46] a nd S ubscriber I D suboption [ RFC 3993] a s 46 follows: 47

• Remote ID suboption SHALL be set to the MS-ID. 48


Page - 180


• Circuit ID suboption SHALL be set to the BS-ID identifying the base station to which the DHCP response 1 message shall be delivered towards the MS. 2

• Subscriber ID SHALL be set to the NAI of the MS. 3

Layer 2 D HCP r elay S HOULD s upport r eporting t he r adio l ink ch aracteristics t o t he D HCP s erver. T he n ew 4 WiMAX Radio Link Characteristics vendor specific suboption contains further suboptions that describe the radio 5 link properties of the MS. The WiMAX Radio Link Characteristics option is defined as a suboption of the DHCP 6 Relay Agent option. The suboptions describing the radio link properties include, among others, the following: 7

• minimum upstream and downstream data rate 8

• maximum upstream and downstream data rate 9

The complete list of suboptions describing the WiMAX radio link characteristic is part of the stage 3 document. 10

7.8.2 R3 Mobility Management with CMIP6 11 This subsection describes requirements and procedures for Mobile IP operation with Ipv6 (CMIP6) [53]. Within the 12 Mobile I P f ramework, an MS with Mobile I P stack maintains a p ersistent I P address when handing o ff between 13 different subnets. Mobile Ipv6 provides the user IP routing service to a NSP’s network. 14

CMIP6 is different from CMIP4 ([43]) in many ways. The most obvious differences are the lack of a foreign agent 15 (FA) in CMIP6, and the support for route optimization (RO) in CMIP6. Instead of a FA, CMIP6 uses a co-located 16 care-of-address (CoA) that is in the mobile node, which is then communicated with the HA using a binding update 17 message. T he C oA ca n b e d erived b y t he mobile n ode u sing s everal methods; t he most co mmon methods ar e 18 stateless auto-configuration [16] a nd s tateful c onfiguration us ing D HCP6 [ 42]. R oute o ptimization i s a nother 19 advantage that CMIP6 has over CMIP4. It will allow the correspondent node to communicate directly to the mobile 20 node without having to transverse the home network. The mobile node registers its bindings with the correspondent 21 node and then the correspondent node will check its binding cache and can route traffic directly to the mobile node. 22 If the correspondent node cannot support the binding cache, then it will simply route the IP packets to the mobile 23 node’s home address and the HA will forward to the CoA. 24

CMIP6 i s ad opted as t he p referred mobility management protocol f or al l ap plicable u sage/deployment s cenarios 25 requiring seamless inter-subnet/inter-prefix layer-3 handovers for Ipv6 based SS/MSs. The R3 Mobility solution has 26 four functional components - a MIP client, a Home Agent (HA) typically located in the user’s home network (but 27 MAY be dynamically assigned/requested from a visited operator’s network), a correspondent node, and an AAA 28 server. 29

A WiMAX mobile node cannot be connected to its MIP6 home network. In other words, the MN never directly 30 connects to its Home Link. To ensure macro mobility between ASNs a subnet cannot span multiple ASNs. To work 31 within these restrictions several assumptions need to be made and enforced. They are as follows. 32

• Each ASN SHOULD be a unique subnet to the Visited CSN. 33

• A MS SHOULD have no more than one (1) MIP “home” network. 34

• The MIP “Home” network SHALL belong to a CSN domain. 35

7.8.2.1 CMIP6 Specific Functional Requirements 36

• Efficient use of wireless link. Extra overhead over the air-interface to accomplish R3 mobility SHALL be 37 minimized. 38

• IP address assignment and host configuration SHALL be performed per Section 7.2.2.2 of this document. 39

• The MIP client SHOULD be located above all physical adaptors and can be integrated into the OS stack. 40

• To support DAD on the MS’s CoA, the ASN-GW which acts as access router SHALL perform proxy DAD 41 function, that maintain all the assigned CoA information and responses to Neighbor Solicitation from MS 42 for DAD. 43


Page - 181


7.8.2.2 Network Initiated Mobility 1 R3 Mobility handover p rocedure i s a lways initiated b y t he ne twork. T he following t ypes o f event can t rigger t he 2 procedure: 3

1) MS mobility: The MS hands off to a new Base Station under a new Access Router. 4

2) Wake-up from idle mode: The MS wakes up from the idle mode under a d ifferent Access Router than the 5 one under which it entered the idle mode. 6

3) Resource optimization: The network decides for resource optimization purposes to transfer the R3 endpoint 7 for the MS from the serving Access Router to a new Access Router, independently of any MS movement. 8

7.8.2.3 CMIP6 Extensions 9 The MIP6 Client SHALL include the NAI Option [59], in all CMIP6 message. 10

7.8.2.4 Mobile IPv6 Operations 11 The following standards SHALL be used for Mobile Ipv6 operation with any limitations or extensions described in 12 this document: 13

• Mobility Support in Ipv6 [RFC 3775]. 14

• Mobile Node Identifier Option for Mobile IPv6 [RFC 4285]. 15

• Authentication Protocol for Mobile IPv6 [RFC 4283]. 16

• draft-ietf-mip6-hiopt-12.txt. 17

7.8.2.4.1 Dynamic Home Agent assignment 18 In r oaming cas es t he H ome A gent can b e as signed b y ei ther t he H ome N SP o r t he V isited N SP. I t’s t he h ome 19 operator t hat will d ecide b ased o n t he r oaming a greement with the visited o perator an d/or t he e nd-user’s 20 subscription profile which network is responsible for assigning the MIP6 Home Agent. 21

If a Home Agent is assigned in the visited network the MIP6 authentication will take place between the visited HA 22 and the Home AAA server. The visited AAA proxy is not involved in the MIP6 security part. 23

If the HA is to be assigned by the Home CSN both the Home Agent address is appended to the AAA reply by the 24 Home-AAA server. For Home Agents in the Visited CSN the AAA proxy can append the Home Agent address to 25 the AAA exchange between the home AAA server and the authenticator. 26

For static agreements between two operator domains (e.g., HA always in the visited network) the AAA proxy can be 27 configured to add a HA address based on the Home-AAA server domain. 28

For more dynamic Home Agent location algorithms (e.g., based on subscription profile) the AAA proxy decision to 29 append to HA address will depend on the presence of the HA address container in the AAA reply from the home 30 AAA. 31

Although not considered very scalable the address of a HA in the visited network can be provided by the home AAA 32 server based on pre-configured information. 33

The H ome Agent i nformation ca n b e p rovided i n t he f orm o f a n I P ad dress o r a FQDN. T he H ome Agent 34 information received from the AAA system is conveyed to the MS via DHCPv6. 35

7.8.2.5 CMIP6 R3 Mobility Management 36 This section describes requirements and procedures for the MIP6 R3 mobility management. 37

At the time of the initial MIP6 session establishment, when a new intra ASN Data Path tunnel is established between 38 the Access Router and the new target BS, the MIP6 cl ient receives new mobile router advertisement messages as 39 defined in section 7.5 of [53] to trigger the MS to perform a new CCoA update and binding update to the HA. 40


Page - 182


IPv6

MIPv6

CS Sub-Layer

802.16eInterface

802.16eInterface PL

Intra ASNData Path

IPv6

Intra ASNData Path

LinkLayer

PL PL

IPv6

MIPv6

Link Layer

PL

HAAccessRouterBSMS CN

PL

Link Layer

IPv6

1

Figure 7-83 - CMIP6 Data Plane with Tunneling 2

IPv6

MIPv6

CS Sub-Layer

802.16eInterface

802.16eInterface PL

Intra ASNData Path

IPv6

Intra ASNData Path

PLPL

LinkLayer

IPv6

MIPv6

Link Layer

PL

CNAccessRouterBSMS

3

Figure 7-84 - CMIP6 Data Plane with RO 4

802.16e

CS Sub-layer

IPv6/MIP6

802.16e

CS Sub-Layer

PL

Intra ASNData Path

PL PL

LinkLayer

IPv6

PL

Link Layer

IPv6/MIP6

HAAccessRouterBSMS

Intra ASNData Path

5

Figure 7-85 - CMIP6 Control Plane 6

The MIP6 cl ient in the MS participates in the message exchanges required to perform anchor CSN mobility. The 7 MIP6 client supports dynamic address assignment and dynamic HA allocation. 8


Page - 183


7.8.2.5.1 CMIP6 Connection Setup and Authentication Phase 1 In o rder for the MS t o authenticate and a uthorize with t he ho me network, t he MS includes t he mobility options 2 carrying the au thentication p rotocol [58]. This t ype o f authentication and authorization a llows the MS to perform 3 Home Registration without IPsec. 4

Upon s uccessful acces s l evel au thentication, t he M S o btains t he AAA-Key/MSK a nd possibly t he H A a ddress 5 allocated to the user. When HA address is not assigned, the MS can obtain the HA address as part of the Mobile IP 6 registration messages exchange. 7

The following signaling flow describes the connection setup phase: 8

MS Access Router HA H-AAA

HA performs proxy DAD for HoA

AAA response

AAA request

BA (IPv6 header | RH Type 2 | Mobility Header (MH Type 6, NAI option, ID option,MN-HA auth option))

BU (IPv6 header | Destination Option Header (HAO) | Mobility Header (MH Type 5,MN-NAI Mobility option, Msg ID option, MN-HA auth option)

a

b

c

d

e

f

g

MS establishes link layer and bootstraps [HL/HA/HoA]

Establish CoA and Create BU with assigned HoA or

autoconfigured HoA

9

Figure 7-86 - CMIP6 Connection Setup 10

a) The MS performs Link Layer establishment. Optionally, the MS acquires bootstrap information from the 11 Home AAA server (via the Access Router). The MS uses stateless DHCPv6 [51] to obtain the bootstrap 12 information. 13

b) If the MS is assigned a new HoA in step a, the MS begins to use it. If no HoA was assigned in step a, the 14 MN g enerates ( auto-configure) an IPv6 global u nicast ad dress. I t MA Y b e b ased o n H ome L ink P refix 15 information if it was received in step a. MS generates a CoA address based on subnet-id received in router 16 advertisement messages. 17

c) At this step the MS sends a Binding Update (Mobility Header type 5) to the selected Home Agent. The MS 18 sets L to 1 if th e M S wants the HA to d efend ( through p roxy D AD) its link-local and global addresses 19 created with the same I ID. The f ields in this BU are set as per [53], [58], and [59]. I n the BU, the MS 20 includes the MN-HA authentication mobility option. 21

d) The HA extracts the NAI, authenticator etc. from the BU and sends an AAA Access Request message to 22 the Home AAA server. This step always occurs for the initial registration regardless of whether the MS is 23 using an auto-configured HoA. 24


Page - 184


e) The Home AAA server authenticates and authorizes the user and sends back an AAA response message to 1 the H A i ndicating s uccessful au thentication a nd a uthorization. A t th is s tep t he H ome AAA server a lso 2 distributes the MN-HA Key to the HA for subsequent MN-HA processing. 3

f) At this step the HA performs replay check with the ID field in the received BU. The HA MAY optionally 4 performs pr oxy Duplicate Address D etection ( DAD) o n the M S’s h ome ad dress ( global) u sing p roxy 5 Neighbor Solicitation as specified in [15]. 6

g) Assuming that proxy DAD is successful, the HA sends back a Binding Acknowledgment (Mobility Header 7 type 6) to the MS. In this BA message the HA includes a Type 2 Routing Header (RH) destined to the 8 MS’s h ome ad dress, t he M N-HA a uthentication mobility option, M N-NAI mobility o ption a nd th e I D 9 mobility option. The MN-HA authenticator is calculated based on the Integrity Key that was derived in the 10 Home AAA server and sent to the HA at step e). 11

7.8.2.5.2 CMIP6 Session Renewal 12 To update session state in the network and allow a co ntext release in case of SS/MS or network failure the MIP6 13 context SHALL be renewed. The client sends Mobile Ipv6 binding update messages to the HA according to [53]. 14 Upon receiving the binding update the HA will reset the MIP6 session timer. Authentication is based on the prior 15 keys obtained during initial authentication and as such do not require a synchronization with the user authentication 16 server. The following depicts the message flow. 17

MS HA

BU (IPv6 header I Destination Option Header (HAO) | Mobility Header (MH Type 5, optionalMN-NA| mobility option, Mesg-ID option, MN-HA auth option)

BA (IPv6 header I RH Type 2| Mobility Header (MH Type 6, optional NAI option, ID option,MN-HA auth option))

a

b

18

Figure 7-87 - CMIP6 Session Renewal, MIP Re-Registration 19

a) The MS sends a BU to the HA. The BU includes ID and the MN-HA authentication mobility options. The 20 BU M AY al so i nclude t he MN-NAI mobility opt ion. T he M N-HA a uthenticator is computed with th e 21 CMIP6-MN-HA key. 22

b) The HA authenticates the BU by verifying the MN-HA authenticator us ing the s tored MN-HA Key. The 23 HA performs replay check. If both authentication and replay check succeeds, the HA sends a B A back to 24 the M S. T he B A co ntains t he MN -HA a uthentication mobility o ption. T he B A c ontains t he M N-NAI 25 mobility option. 26

Replay pr otection i s pr ovided u sing the M obility message i dentification opt ion a s s pecified i n [58]. T imestamp 27 based r eplay pr otection i s us ed i n t his doc ument f or t he bot h M N-AAA a nd M N-HA a uthentication mobility 28 options. 29

7.8.2.5.3 MIP6 Inter Access Router Handovers 30 As p reviously mentioned, C MIP6 R 3 m obility handovers a re a lways network i nitiated. E ven when t he mobile 31 initiates the handover to a new BS and Access Router, the R3 mobility is a result of a network event that strives to 32 minimize impact on real time traffic when migration R3 from anchored to serving Access Router. 33


Page - 185


7.8.2.5.3.1 Inter Access Router Handover 1 The following flow diagram describes the inter Access Router handover. 2

MS BSIntra-ASN

Functional entity

TargetData PathFunction

TargetAccessRouter

ServingData PathFunction

ServingAccessRouter HA

9 ASN Data Path

(1) Old ASN Data Path

4) New CoACalculated

10) Remove the old Intra-ASN Data Path

2) Anchor_DPF_Relocate_Request

5) Binding Update

3) Router Advertitisement

6) Binding Acknowledgement

8a) Anchor_DPF_Relocate_Rsp

7) Target ARdetermines thestatus of BU/BA

8b) Relocate_Cnf

3

Figure 7-88 - CMIP6 Mobility Event Triggering a Network Initiated R3 Re-Anchoring (CMIP6) 4

1-2) Old Access Router: Arrows 1 represent the old intra-ASN data path prior to handover. 5

2) Inter/Intra-ASN mobility trigger: R3 handovers is initiated by an ASN Functional Entity. 6

After s uccessful R3 Handover t he I ntra-ASN F unctional e ntity is notified by a n R 3 Anchor_DPF_Relocate_Rsp. 7 This message is acknowledged by sending the R3 relocation.Confirm. This completes the establishment of the new 8 MIP context. 9

3) Upon receiving R3 mobility relocation trigger, target Access Router sends router advertisement to MS. 10

5-6) MIP context update: New binding with the HA is created. 11

7) The Target AR determines the state of the MIP6 registration process by parsing the BU/BA in a p assive 12 mode. 13

8) Inter-ASN context update: After successful R3 Handover the Intra-ASN Functional entity is notified by an 14 R3 Relocation_Rsp. In case of an unsuccessful handover the Intra-ASN Functional Entity is also informed 15 so that the old states can be restored. 16

9) Establishment of new Intra-ASN tunnel: Together with an R3 re-anchoring also new intra-ASN Data Paths 17 need to be established. 18


Page - 186


10) Upon successful R3 relocation the old ASN Data Path between serving and target Access Routers can be 1 released. 2

7.8.2.5.4 Router Advertisements 3 The router advertisements are sent as per IPv6 address configuration procedures. 4


Page - 187


7.8.2.5.5 MIP6 Session Termination 1 In the case where a MS’s IPv6 session has to be terminated, the MIP6 binding state between the MS and the HA has 2 to be gracefully removed. 3

The two termination scenarios are: 4

• An MS initiated graceful termination: a session is gracefully terminated by sending a MIP6 binding update 5 message with lifetime = 0. This termination is triggered either by the user or MS being in an error 6 conditions such as low battery power, etc. 7

• Network initiated graceful termination: a session is gracefully terminated by sending an 8 R3_Session_Release.Request message from the ASN-Functional Entity to the Serving Access Router. The 9 AR can in turn send a RA to the MS with Router Lifetime set to 0. This will force the MS to terminate its 10 IPv6 session with the AR. This should also prompt the MS to send a binding update with the lifetime=0 to 11 the HA. For transport of the BU/BA, the AT needs to keep the IPv6 session alive until the MS is able to 12 de-register successfully with the HA. This will require the AR to inspect the BU/BA in a passive mode so 13 that it can determine when to remove the IPv6 session state with the MS and initiate R6 teardown. The 14 conditions for network initiated termination MAY be some error conditions with respect to the MS such as 15 the MS being identified as a rogue MS with security violations, planned maintenance, etc. This scenario is 16 depicted in Figure 7-89. 17

5) passive BU/BAparsing

MS AccessRouter

Access RouterDP HA

1) R3_Session_Release Req(MSS_ID)

2) Mobility Advertisement withlifetime=0

3) Biding Update withlifetime=0

4) Biding Acknowledgementwith lifetime=0

6) R3_Session_Release Reply(MSS_ID)

18

Figure 7-89 - CMIP6 Network Initiated Graceful Termination 19


Page - 188


7.8.2.5.6 Dynamic Home Agent Assignment via CMIP6 Bootstrap 1 The Home AAA server allocates the Home Agent and the Home Link Prefix to an MS during access authentication 2 using MIP6 Home Agent attribute/AVP and MIP6 Home Link Prefix attribute/AVP. The MS obtains the assigned 3 HA information using stateless DHCPv6 procedures as described in Figure 7-90. 4

Store HA and HL info

Begin Access-Auth

Complete Access-Auth

Assign HA and HL

MN AR Home AAA

AAA request

AAA response

(HA and HL)

a

b

c

d

e

f

g

h

Information-Request [O-R-O]

Reply [HA and HL options]

5

Figure 7-90 - Flow Diagram for Dynamic Home Agent Assignment 6

a) The MS begins the Access Authentication procedure. 7

b) The AR sends AAA request to the Home AAA server. 8

c) The Home AAA server verifies the user’s profile and detects that the user is a MIP6 subscriber. The Home 9 AAA server assigns an HA and a Home Link Prefix for the MS. 10

d) The H ome AAA s erver i ncludes a H ome Agent ad dress i n t he M IP6 H ome Agent attribute/AVP. T he 11 Home AAA server also includes a Home Link Prefix in the MIP6 Home Link Prefix attribute/AVP. 12

e) The AR receives the HA and HL information attributes/AVPs from the Home AAA server and stores them. 13

f) The Access Authentication procedure completes at this step. 14

g) The MS requests MIP6 bootstrap information using the DHCPv6 Information-request message [51] sent to 15 the AR. The MS uses the opcodes in the O-R-O for MIP6. The Opcodes are defined in draft-jang-mip6-16 hiopt-12.txt. 17


Page - 189


h) The ASN looks up the appropriate record based on the Client Identifier and replies back to the MS [51] 1 with the opt ions that were requested, a ttaching the HA information in a DHCP WiMAX Vendor Option 2 with a Vendor-Specific O ption-Code=1. I t al so at taches t he H L information i n a D HCPv6 o pcode as 3 defined in draft-jang-mip6-hiopt-12.txt. 4

7.8.2.5.7 Dynamic Home Link Prefix Discovery via CMIP6 Bootstrap 5 The H ome L ink P refix i nformation i s d elivered t he A R during t he a uthentication s etup p hase. T he H ome AAA 6 server selects the Home Link Prefix and includes it in a MIP6 Home Link Prefix attribute/AVP in the AAA response 7 message indicating s uccess. T he H ome Link P refix information i s d elivered t o t he MS when t he M S sends a 8 DHCPv6 Information-Request message. 9

Begin Access-Auth

Assign HL

Store HL info

Complete Access-Auth

MN AR Home AAA

Information-Request [O-R-O]

Reply [HL option]

a

b

c

d

e

f

g

h

AAA request

AAA response(Home-Link prefix)

10

Figure 7-91 - Bootstrap of Home Link Prefix 11

a) The MS begins the network access authentication procedure. 12

b) The AR sends AAA request to the Home AAA server. 13

c) The Home AAA server detects that the user is a MIP6 subscriber by verifying with the user’s AAA profile. 14

d) The Home AAA server assigns a HL prefix for the MS. 15

e) The H ome AAA s erver i ncludes t he a ssigned H ome Link P refix i n a n AAA M IP6-Home Link P refix 16 attribute/AVP. 17


Page - 190


f) The AR receives the HL information from the Home AAA server. The AR stores the HL information. The 1 access authentication procedure completes at this step. 2

g) The MS requests the MIP6 bootstrap information using the DHCPv6 Information-request message [51] sent 3 to the AR. The MS uses the opcodes in the O-R-O for MIP6. The Opcodes are defined in draft-jang-mip6-4 hiopt-12.txt. 5

h) The AR looks up the appropriate record based on the Client Identifier and replies back to the MS [51] with 6 the options that were requested and attaches the HL information in a DHCP option as specified in draft-ietf-7 mip6-hiopt-12.txt. 8

With t he a ssigned H ome Link P refix, t he M S p erforms d ynamic Home Agent Address d iscovery b y using t he 9 procedure defined in [53] Section 5.3. The MS also auto-configures a Home Address with the assigned Home Link 10 Prefix. 11

7.8.2.5.8 Dynamic Home Address Configuration 12 The MS is a llowed to perform stateless a uto-configuration of i ts Home Address based on the Home L ink P refix. 13 Alternatively, the MS MAY be assigned a Home Address by DHCPv6 [42]. In either case, the Binding Cache Entry 14 (BCE) Lifetime is limited by the home-link prefix lifetime at the HA. This is controlled by the HA via the lifetime 15 field in the Binding Acknowledgement message sent to the MS. The MS can request an extension to the HoA/BCE 16 lifetime by sending a Binding Update to the Home Agent. 17

Once the BCE expires, the MS SHALL NOT use the HoA from the expired session. The MS SHALL initiate the 18 bootstrapping procedure when starting a new MIP6 session if the MS does not have the registration information (i.e., 19 HL Prefix, HoA, HA) provisioned. 20

If the Binding Refresh Advice mobility option is present in the BA message [53], the Refresh Interval field in the 21 option SHALL be set to a value less than the lifetime value being returned in the Binding Acknowledgement. This 22 indicates t hat the mobile node SHOULD a ttempt to refresh it s home registration a t t he indicated shorter in terval. 23 The HA SHALL still retain the registration for the BCE lifetime period, even if the mobile node does not refresh its 24 registration within the refresh period. However, i f the mobile node does not refresh the binding by sending a new 25 BU to the HA before the BCE lifetime expires, the HA SHALL delete the BCE. 26


Page - 191


7.8.2.5.9 Home Address Assignment by DHCPv6 1

7.8.2.5.10 Home Address Auto-Configuration by the Mobile Station 2

MNautoconfigures

the HoA

MS AR H-AAA

Information-Request (O- R- O)

Reply [HL/HA/HoA option]

a

b

c

d

EAP-PKMv2

3

Figure 7-92 - Home Address Auto-Configuration 4

a) The MS performs Device Authentication using EAP-PKMv2. 5

d) The MS requests the MIP6 bootstrap information using the DHCPv6 Information-request message [51] 6 sent to the AR. The MS uses the Opcodes in the O-R-O for MIP6. The Opcodes are defined in draft-jang-7 mip6-hiopt-12.txt. 8

e) The AR looks up the appropriate record based on the Client Identifier and replies back to the MS [51] 9 with the MIP6 bootstrap options. 10

f) Upon receiving the MIP6 bootstrap information from the AR, the mobile station checks whether a HoA 11 is included or not. If HoA is not included, the MN uses the Home Link Prefix. The MN auto-configures the 12 Home Address in a stateless manner as described in [16]. 13

7.8.2.6 Home Agent Requirements to Support Dynamic Home Agent Assignment 14 The HA SHALL support Dynamic Home Agent Address Discovery as defined in [53]. 15

The HA SHALL process Binding Updates that contain Mobility message authentication options (MN-HA or MN-16 AAA), Mobility message Identification (ID) option and MN-NAI mobility option. 17

7.8.2.7 Home Agent Requirements to Support Dynamic Home Address Configuration 18 The H ome Agent S HALL support H ome Addresses t hat a re ei ther as signed b y t he H ome AAA s erver o r au to-19 configured by the Mobile Station as long as the use of the Home Address by the user (NAI) is authorized by the 20 Home AAA server and the p roxy Duplicate Address Detection p rocedure on the Home Link p asses. In t he case 21 where the MS uses an auto-configured HoA, no authorization check against the HoA is performed by the Home 22 AAA server. The HA does not include the HoA information in the AAA request message. 23

Upon receiving a Binding Update containing Mobility Message Authentication Mobility Options (MN-HA or MN-24 AAA), M obility M essage M obility M essage r eplay p rotection o ption, MN -NAI mobility opt ion a nd a H ome 25 Address Option (HAO) with a unicast Ipv6 address in the Home Address field, the HA SHALL process the Binding 26 Update. The HA SHALL perform proxy Duplicate Address Detection for the requested Home Address as per RFC 27


Page - 192


3775. The lifetime in the Binding Acknowledgement is controlled by local configuration at the Home Agent or it is 1 set to the valid-lifetime remaining for the home-link prefix ([15], Section 4.6.2). 2

7.8.2.8 Multiple Registrations 3 The H A S HALL s upport multiple h ome r egistrations with th e same N AI b ut d ifferent H ome Addresses. T he 4 Binding Cache E ntry (BCE) in t he H A S HALL be i ndexed with the NAI and the Home Address o f the MS a t a 5 minimum. The H A SHALL rely on the Home AAA server to authorize a user to perform multiple simultaneous 6 home registrations on the same home link. 7

The MS is allowed to send more than one Binding Update for home registration with different HoA and with same 8 or different CoA. Whether these home registrations will be allowed or disallowed depends on the Home Network 9 provider’s p olicy. I f multiple r egistrations a re not a uthorized, th e H A will r eceive a n AAA response message 10 indicating failure for subsequent home registration authorization. 11

7.8.2.9 Home Registration Support 12 The HA SHALL support the Authentication Protocol [58] based Home Registration. 13

The HA SHALL support Mobile IPv6 authentication protocol as defined in [58] and the MN-NAI mobility option as 14 defined in [59]. U pon receiving the BU, the HA SHALL perform authentication of the BU based on the Mobility 15 authentication option contained in the BU and the MN-NAI mobility option. 16

7.8.2.10 Return Routability Support for Route Optimization 17 The H ome Agent SHALL support R eturn Routability ( RR) for R oute O ptimization a s s pecified i n [ 53]. T hese 18 messages MAY be protected on a hop-by-hop basis through the operator’s network. 19

7.8.3 MIP-based Ethernet Services over R3 20 Note: Most likely Ethernet services are provided using Simple Ethernet. Simple Ethernet services may not be able to 21 perform CSN a nchored mobility. T he b earer o f t he R 3 interface for S imple E thernet i s o ut o f scope o f t his 22 specification. For MIP-based Ethernet services, the rest of this section specifies the operation over the R3 interface. 23

Ethernet services require that subscriber’s Ethernet frames are transported from the point of attachment in the access 24 network to the Ethernet service provider. In WiMAX® systems the point of attachment is ASN and the Ethernet 25 service p rovider i s connected through the CSN. T his s ection d escribes t he i nterface between ASN and CSN t hat 26 supports the t ransport o f Ethernet f rames for MIP-based Ethernet services. This interface i s based on the existing 27 Proxy MIP4 solution available in Rel 1.0. Proxy MIP4 is enhanced to support Ethernet services. There are several 28 advantages to using the existing Proxy MIP4 interface for Ethernet services: 29

- no modifications to the network reference model are required 30

- requires only incremental changes to the existing Proxy MIP4 interface 31

- provides for Ethernet services the same network support as available for IP services in terms of network 32 sharing, security and QoS architecture, roaming and mobility 33

- allows to keep the same business model as for IP services with NAPs, NSPs, ASN sharing and roaming 34

As the protocol stack in the Figure 7-93 shows, Ethernet frames originated by the MS are transparently transported 35 to the CSN. F rom the perspective of the MS, the ASN together with the HA in the CSN is behaving l ike a plain 36 Ethernet connection (E-Line). 37


Page - 193


BS ASN-GW

ASN

CSN CSNMS

R1

R6

R3 R5

MACPHY

ETHETH CS

Control

Data Path

MACPHY

ETHETH CS

IP

PHY

ETHGRE

LINKIP

PHY

ETHGRE

LINKPHY

ETH

IPLINK

PHY

ETH

IPLINK

PHY

ETHLINK

PHY

ETHLINK

PHY

MIPv4IP

LINKPHY

MIPv4IP

LINKPHY

DP FnIP

LINKPHY

DP FnIP

LINKPHY

16 CNTLMAC

PHY

16 CNTLMAC

GREGRE

1

Figure 7-93 - Ethernet Services control plane and data plane protocol stack 2

7.8.3.1 Connection Setup Phase for Ethernet Services 3 Access au thentication p hase is the s ame as f or t he I P C S b ased M S. The A AA s erver d elivers P roxy M IP4 4 information to the authenticator in the ASN. The AAA server will also deliver the PDF descriptor authorizing the 5 use of Ethernet services. 6

After the ETH CS ISF is established, the authenticator will tr igger the collocated PMIP client to register with the 7 HA. In any case, the PMIP client starts the establishment of an R3 tunnel by generating the RegistrationRequest 8 message and relaying it to the collocated FA. The RegistrationRequest will contain the MS NAI, IPv4 home address 9 field will be set to al l zeros and the MS ID address will be included in the new MIP4 Device ID. When the FA 10 forwards the RegistrationRequest to the home agent, it will request GRE encapsulation. In addition to setting the G 11 flag in R egistrationRequest m essage, t he F A will a lso a llocate th e G RE k ey a nd will in clude it in th e G RE 12 extension. When the home agent receives the RegistrationRequest message, it will bind the MS ID contained in the 13 Device ID extension to the FA CoA. It will also save the received GRE key as part of its mobility binding context. 14 Home agent will also allocate its own GRE key and send it to FA in MIP Registration Reply. 15

After successful registration, the home agent will start capturing the Ethernet frames on the home l ink destined to 16 the registered MS ID and forwarding those frames to the FA via GRE tunnel. The home agent must include the FA’s 17 GRE key in the GRE packet header. Based on the received GRE key, the FA will identify the MS to which the 18 frame must be delivered. The FA will not use the data from the inner packet header (i.e. MAC addresses) to identify 19 the corresponding MS. This i s advantageous in case that t here are multiple devices connected to a b ridge behind 20 MS. In such case, the bridge attached to t he home agent can learn the MAC addresses of the hosts behind the MS 21 when those hosts become act ive and send some uplink frames. H aving learnt the address(es) behind the MS, the 22 bridge behind the home agent would start tunneling the frames on the home link destined to those MAC addresses 23 over the established GRE tunnel, tagging the tunneled packets with the GRE key associated with the MS. FA will 24 look at the received GRE key in order to identify the MS to which the encapsulated payload must be delivered. In 25 the uplink direction, the home agent will use the received GRE key ( instead of the source address from the inner 26 header) to find the corresponding mobility context. 27

At this point, after successful registration of an R3 tunnel, MS is free to use any higher layer protocols, such as IPv4 28 or IPv6, without any special considerations. 29

The f ollowing message s equence chart illustrates t he signaling f low for e stablishing the R 3 connection upon the 30 initial network entry. 31


Page - 194


MS HAH-AAAASNFA/PMIP client

(2) ISF established

(4) RRP(OK, GRE uplink key)

(3) RRQ(NAI, GRE downlink key, MS MAC)

(1) Access authentication

1

Figure 7-94 - Initial attachment in case of Ethernet services 2

1. In s tep 1 t he M S i s au thenticated f or n etwork acces s. T he H -AAA will p rovide th e P acketDataFlow 3 descriptor authorizing the use of Ethernet services. 4

2. If t he MIP based Ethernet Service is authorized and the establishment o f Eth CS ISF is completed, the 5 authenticator triggers the collocated PMIP client to start the PMIP registration process. 6

3. The P MIP cl ient g enerates t he MI P R egistrationRequest message co ntaining t he M S N AI. T he s ource 7 address of the message is the IP address of the PMIP client. In addition, the PMIP client requests the use of 8 GRE encapsulation and adds a GRE key as per [102]. PMIP client also adds a MIP extension carrying the 9 MS MAC address. The PMIP client relays the Registration Request message to the collocated FA. The FA 10 relays the message to the HA. The HA detects that the incoming registration requires the use of Ethernet 11 services based on the presence of a M AC address extension. The HA creates a new mobility binding and 12 saves NAI, MAC address and the received GRE key as part of the binding. 13

4. If t he H A supports E thernet s ervices, i t generates i ts o wn GRE key a nd s ends i t to t he FA in t he 14 Registration response message indicating success. At this point HA starts capturing any Ethernet frames on 15 the home link matching the MAC address from its mobility binding and tunnels the captured frames over 16 the associated tunnel. The HA will also tunnel Ethernet broadcasts from the home link to all registered MS 17 that are using Ethernet service. 18

7.8.3.2 Proxy MIP Session Renewal for Ethernet Services 19 Refer to section 7.8.1.8.4 for Proxy MIP session renewal procedure. The MIP registration request MUST contain the 20 MS MAC address extension. 21

7.8.3.3 CSN-anchored Mobility Management Handover for Ethernet Services 22 Refer to section 7.8.1.8.5 for Proxy MIP anchored mobility management handover procedure. 23

7.8.3.4 Session Termination for Ethernet Services 24 The Proxy MIP session may be terminated by the PMIP client, HA or the Anchor DPF. Refer section 7.8.1.8.6 for 25 the case where the Proxy MIP session is terminated by the PMIP Client. 26

7.8.3.4.1 Session Termination Tr iggered by Anchor DPF 27

The following sequence chart describes the removal of PMIP session by FA_Revocation procedure when the trigger 28 is received to remove the Eth CS ISF from the Anchor DPF. 29


Page - 195


MS HAPMIPanchor DPF

(2) FA_Revoke_Req

(3) Registration Revocation Message

(4) FA_Revoke_Rsp

(5) Registration Revocation Acknowledge Message

1) Eth CS ISF removed

1

Figure 7-95 - Session Termination by Anchor DPF 2

Step 1 3

The trigger for removal of PMIP session is the removal of the Eth CS ISF. When the anchor DPF detects that the 4 ISF has been deleted, it shall initiate the removal of a PMIP session. 5

Steps 2 and 3 6

The anchor DPF initiates the session release with PMIP4 client and HA concurrently by sending FA_Revoke_Req 7 and Registration Revocation messages, r espectively. T he R egistration Revocation message contains the M S NAI 8 which is used by the HA to identify the mobility binding which needs to be removed. 9

Steps 4 and 5 10

FA_Revoke_Rsp and Registration Revocation acknowledgement messages are received from PMIP4 client and HA, 11 respectively. HA, FA and the PMIP client remove all state associated with the MS. The HA stops capturing Ethernet 12 frames on the home link. 13

14

The following sequence chart describes the removal of PMIP session by MIP RRQ with life time=0 procedure when 15 the trigger is received to remove the Eth CS ISF from the Anchor DPF. 16

MS HAASNc(PMIP)ASNa (ADPF)

(2) Anchor_DPF_Release_Req

(4) RRQ (lifetime = 0)

(5) RRP

(3) FA-Register-Req (RRQ(lifetime=0))

(6) FA-Register-Rsp (RRP)

1) Eth CS ISF removed

17

Figure 7-96 - Session Terminated by DPF 18

Step 1 19


Page - 196


The trigger for removal of PMIP session is the removal of the Eth CS ISF. When the anchor DPF detects that the 1 ISF has been deleted, it shall initiate the removal of a PMIP session. 2

Step 2 3

The ASNa initiates the session release with PMIP4 client by sending Anchor_DPF_Release_Req Message. 4

Step 3 5

Upon receipt of Anchor_DPF_Release_Req the ASNc sends FA-Register-Req (RRQ(lifetime=0)) to ASNa. 6

Step 4 7

Upon receipt of FA-Register-Req ASNa, extracts and relay the RRQ (lifetime = 0) to HA. 8

Step 5 9

The HA removes the binding and replies with RRP. 10

Step 6 11

After receiving RRP, ASN(a) sends FA-Register-Rsp (RRP) to the ASN(c) 12

13

7.8.3.4.2 Session Termination Tr iggered by HA 14

The following sequence chart describes the removal of PMIP session when the HA decides to remove the mobility 15 binding with the FA. 16

MS HAPMIP Client

Anchor DPF/FA

(4) FA_Revoke_Req

(2) Registration Revocation

(5) FA_Revoke_Rsp

1) Session Termination

Trigger

(3) Registration Revocation Acknowledge

17

Figure 7-97 - Session Termination by HA 18

Step 1 19

The HA decides to terminate current mobility binding with the FA and hence initiates session termination. 20

Steps 2 and 3 21

The HA sends a Registration Revocation to the Anchor DPF/FA. The Registration Revocation contains the MS NAI 22 which i s used b y t he F A t o identify t he mobility bi nding which needs to b e r emoved. The F A r esponds with a 23 Registration Revocation Acknowledgement to confirm the receipt of the request. Upon receipt of this response, the 24 HA stops capturing Ethernet frames on the home link. 25

Steps 4 and 5 26

Concurrently, the FA also sends FA_Revoke_Req to the PMIP4 client. Once the FA_Revoke_Rsp from the PMIP 27 client is received at the FA, it removes all states associated with the MS. 28


Page - 197


7.8.3.5 Coexistence for Networks supporting Ethernet Services (Simple and MIP based Ethernet 1 Services) with IP Services (PMIP and Client MIP and Simple IP) 2

Ethernet Services provided to one MS can coexist with IP based services provided to another MS. One example is 3 when GRE is used on R3 for carrying IP traffic as well as Ethernet traffic and the HA is extended to a dual mode 4 device with the capability to distinguish between IP-traffic and Ethernet traffic based on the TYPE field in the GRE 5 header. The routing model for IP traffic has to be complemented by a bridging model for the Ethernet traffic. Details 6 of the bridging model in the HA is given in the section 7.8.3.6. The other example is statically configured data path 7 protocol of R3 and R5, which is out of scope of this document. 8

7.8.3.6 Bridging behavior of HA for Ethernet Services 9 The b ehavior o f a H A i s specified i n [ 43]. S ection 4. 2.3 of [ 43] pr ovides c onsiderations a bout forwarding o f 10 datagrams by the HA in the home network. 11

For E thernet s ervices, t he forwarding be havior of t he HA h as t o be a dapted f or handling frames ba sed o n 12 encapsulated E thernet h eader i nformation instead o f en capsulated I P h eader i nformation. Logically the H A f or 13 Ethernet Services consists of a GRE tunnel termination entity attached to an Ethernet bridge according to IEEE Std 14 802.1D and IEEE Std 802.1Q providing a virtual port for each of connected MS. Bridge ports may either configured 15 as host p ort, when p lain E thernet p ackets ar e forwarded t o t he MS , o r a s t runk p ort, when E thernet f rames 16 containing VLAN tags are forwarded to the MS. The binding between the bridge port and the assigned MS is done 17 by the individual GRE key, which is assigned to each of the MS and is used as l ink identification inside the GRE 18 tunnel between the HA and the FA. 19

Frames ex iting t he b ridge o n a p articular p ort ar e en capsulated i n G RE p ackets with t he G RE key set t o t he 20 particular identifier for the MS associated to the port. When GRE packets containing Ethernet frames are arriving at 21 the HA from the FA, the HA extracts the Ethernet frame and forward the frame towards the bridge port which is 22 indicated by the GRE key as the port associated with the MS sending the Ethernet frame. 23

The b ehavior o f t he b ridge may b e e nhanced f or E thernet f rames car rying I P d atagrams acco rding t o [ 85] fo r 24 increased efficiency and lower power consumption of the Mobile WiMAX® access network. 25

7.8.4 R3 mobility management with PMIP6 26

7.8.4.1 Scope 27 PMIP6 is the network-based mobility management protocol providing IP session continuity for MS that changes its 28 topological point of attachment in the network [99]. The MS is not involved in mobility signaling and thus it is not 29 aware of the PMIP6 procedures within the network. Throughout the IP session, the MS retains its persistent Home 30 Address, and perceives being continuously attached to the same IP link. At the occurrence of L3 handover, the MS’s 31 data path changes as result of the R3 tunnel relocation by PMIP6 procedures. 32

The PMIP6 relies on two types of mobility entities, Mobile Access Gateway (MAG) located in the ASN, and Local 33 Mobile Anchor ( LMA) p resent i n the C SN (or i n a non-WiMAX® network s uch a s 3GPP EPC in case of inter-34 technology i nterworking). The W iMAX P MIP6 d omain is d efined as per [99], where mobility area may i nclude 35 home- and visited WiMAX network domains (NAP/NSP) corresponding to the WiMAX Forum® Network 36 Architecture NRM. Proxy Mobile IPv6 may be used to interwork with other access technologies. 37

PMIP6 complements the ASN anchored mobility management procedures, and can coexist with other IP Services 38 supported in WiMAX, i.e., Simple IPv4, Simple IPv6, PMIP4, CMIP4 and CMIP6. Functional overlapping between 39 PMIP6 a nd ot her I P S ervice pr otocols a re pos sible i n s pecific network de ployments when multiple I P M obility 40 Services are supported within the same ASN/CSN. 41

7.8.4.2 Functional requirements 42 Specification [99] provides the architectural and operational PMIP6 model as it defines the two functional mobility 43 management entities: 44

Local M obile Anchor (LMA) - topological mobility a nchor m aintaining r eachability f or th e M S while r esiding 45 within th e P MIP6 domain. L MA is e xpected to im plement f unctional c apabilities o f th e C MIP6 H ome A gent 46 enhanced with protocol extensions required for PMIP6 support. 47


Page - 198


Mobile Access Gateway (AR/MAG) – functional entity in the ASN that manages PMIP6 mobility-related signaling 1 on behalf of the MS and serves as endpoint of the transport data path towards the LMA. For a non-integrated ASN 2 that supports PMIP6, the MAG function is always embedded within the first-hop AR in the ASN-GW. 3

The functional architecture o f WiMAX® PMIP6 SHALL a lso include the Authenticator/NAS function, and M AY 4 include DHCP Proxy/Relay entities in specific deployments. 5

• PMIP6 mobility management in WiMAX networks SHALL be based on procedures specified in [99] and 6 [100]. 7

• PMIP6 SHALL support mobility for IPv6 and dual-stack hosts with both IPv4 and IPv6 stacks, and SHALL 8 support IPv4 host mobility if a coexisting alternative mobility management service (PMIP4) does not take 9 precedence. IP Mobility service with PMIP6 is provided to MSs authorized by the home network. 10

• During th e i nitial e ntry p rocess, the Authenticator in ASN r etrieves t he s ubscriber p rofile, I P s ervice 11 indication, a nd al l r elevant s ecurity p arameters from t he d edicated A AA server i n CSN b y means o f 12 applicable AAA message transaction (RADIUS or Diameter). 13

• When multiple I P s ervice o ptions co exist i n t he s ame W iMAX network, t he ch oice o f t he I P mobility 14 protocol to be used for the establishing MS session is entirely based on the network’s decision. 15

• During the IP service session the MS retains the same IP MN-HoA assigned at the time of initial network 16 entry. The ASN SHALL accommodate appropriate host IP configuration and addressing mechanisms such 17 as N eighbor D iscovery Protocol o r D HCP o peration, ach ieving that M S will n ot b e a ware o f i ts act ual 18 movement within the PMIP6 domain. 19

• PMIP6 SHALL utilize WiMAX specific R4/R6 signaling to further improve on the protocol operation and 20 handover performance. 21

• Communication b etween M S an d r emote co rrespondents SHALL b e ach ieved i n r everse d elivery s tyle, 22 where data path always traverses through the LMA. 23

• For non-roaming scenarios PMIP6 LMA SHALL be assigned in the HCSN. For a M S roaming in visited 24 network t hat supports PMIP6, the LMA M AY be allocated from V CSN or HCSN as subject of r oaming 25 agreement and individual subscriber policy. PMIP6 LMA may be in a non-WiMAX network such as 3GPP 26 EPC in case of inter-technology interworking. 27

7.8.4.2.1 LMA considerations 28

• The LMA SHALL implement PMIP6 extensions as defined in [99]. 29

• The L MA t opologically a nchors t he M S’s h ome l ink, maintains i ts r eachability by e nforcing the co rrect 30 routing state, and participates in the Home Address assignment process. 31

• Allocation and discovery of LMA for a particular MS SHALL be accomplished through AAA interactions. 32

• The LMA SHALL implement two modes of PMIP6 security: One using RFC 4285 [58] (in-band security), 33 and the other not using any PMIP6-specific security but relying on the R3/R5 control plane security (lower-34 layer security). NSP and NAP decide which mode to operate based on their local policy and the dynamic 35 negotiation during the network access authentication of the MS. HAAA can deny authorization of a PBU 36 received by the LMA if the PBU does not comply with the agreed security mode. 37

• The LMA SHALL ensure that there is a valid direct or indirect trust relationship between the MAG and 38 itself b efore a llowing th e MAG to c reate mobility b inding o n b ehalf o f t he M S. P ossible a uthorization 39 mechanisms may include but are not limited to AAA queries, configured authorization lists, policy function 40 checks, etc. 41

• The LMA SHALL support mobility of IPv4 hosts, and provide the IPv4-based transport mechanism over the 42 R3 interface using procedures and functionalities specified in [100]. 43

7.8.4.2.2 MAG considerations 44

• The MAG is the IP mobility function specific to PMIP6 and it is located in the ASN-GW/ASN. The MAG 45 functionality is specified in [99]. 46


Page - 199


• The MAG SHALL always be located on MS’s data path as it is collocated with the Anchor DPF. 1

• The MAG SHALL provide the necessary capabilities for IP data path setup and management of transport 2 tunnel over the R3 reference point. This includes support the minimal set of IP encapsulation methods and 3 mechanisms for diversification of data flows tunneled over the R3. For more details refer to section 7.8.4.4. 4

• It i s expected that ASN mobility p rocedures SHALL supplement PMIP6-based handovers as to minimize 5 the packet loss and improve the overall handover efficiency. The optimized handover procedure SHOULD 6 include t he e xchange o f P MIP6 m obility c ontext a t t he phase when l ink l ayer handover i s p repared o r 7 executed. 8

• The MAG M AY incorporate support for specific L2/L3 trigger mechanisms s erving as i ndication of MS 9 attachment or detachment. 10

• The MAG learns the address of the assigned LMA from the AAA profile. 11

• Communication between the two correspondents attached to the same MAG SHALL always take place over 12 the R3 tunnel and the associated LMA in the CSN. The MAG SHALL NOT make use of the local routing 13 feature. 14

• The MAG SHALL implement two modes of PMIP6 security: One using RFC 4285 ( in-band security), and 15 the other not using any PMIP6-specific security but relying on the R3/R5 control plane security (lower-layer 16 security). N SP an d N AP d ecide which mode t o o perate b ased o n t heir l ocal p olicy an d t he d ynamic 17 negotiation during the ne twork access authentication of the MS. MAG SHALL learn the negotiated mode 18 from the authenticator in order to generate the PBU and process the PBA accordingly. 19

7.8.4.2.3 Authenticator /NAS consider ations 20

• The Authenticator/NAS SHALL negotiate the PMIP6 security mode with the HAAA. It SHALL make that 21 information available to the MAG. 22

• If the negotiated security mode is in-band, then the Authenticator/NAS SHALL facilitate authentication and 23 authorization functions with the a im to acquire, store and distribute keys a nd related security in formation 24 required for PMIP6 operation. Authenticator SHALL interwork with MAG in the process of establishing the 25 LMA trust relationships and appropriately securing mobility signaling. 26

• During t he i nitial ne twork e ntry p hase t he Authenticator/NAS a nd M AG S HALL b e co-located. I n cas e 27 when Anchor DPF and Authenticator relocation procedures are conducted independently, the two functional 28 entities MAY end up split between different ASN-GWs. 29

Additional requirements and demands on the Authenticator/NAS and AAA framework are defined in Section 7.3. 30

7.8.4.2.4 DHCP Proxy/Relay considerations 31

• The MAG and the DHCP Proxy/Relay functions are collocated. 32

• The network SHALL provide IPv6 address autoconfiguration or the IPv6 stateful address configuration 33

• If DHCPv6 Proxy or Relay functionalities are not available, the network SHALL set the flags appropriately 34 in the RA sent (un)solicited to the MS. 35

• The use of DHCPv6 s tateful address configuration SHALL be as per [99] section 6 .11 with the extension 36 that the network deployment MAY support either one of DHCP Relay or DHCP Proxy functions. 37

• For IPv4 host mobile access via PMIP6 requirements from section 7.2.1.1.3 apply. In this case the network 38 SHALL provide either the DHCPv4 Proxy or Relay function in the ASN. 39

7.8.4.3 Security requirements 40 There are two mandatory-to-implement a nd optional-to-use security modes for PMIP6: One using RFC 4285 ( in-41 band security), and the other not using any PMIP6-specific security but relying on the R3/R5 control plane security 42 (lower-layer security). NSP and NAP decide which mode to operate based on their local policy a nd the d ynamic 43 negotiation during the network access authentication of the MS. 44


Page - 200


• At least one o f t he lo wer-layer security o r in -band security SHALL be used. Lower-layer security can be 1 used i f a nd o nly i f R 3 a nd R 5 ( when us ed) a re s ecured ( integrity a nd r eplay pr otected, da ta origin 2 authenticated). In-band security SHALL be used in the absence of secure R3/R5. 3

• Trust r elationship M UST b e established b etween L MA an d i ts co rresponding M AGs. I n cas e o f i n-band 4 security, t his relationship is c ryptographically verified b etween the LMA a n MAG (i.e., keys a nd signed 5 messages are used between the two). In case o f lower-layer security, LMA and MAG are not involved in 6 any cr yptographic verification, but i nstead rely on the NSP and NAP n etwork d omains t o ensure P MIP6 7 signaling is generated by the authorized entities. 8

7.8.4.4 Data and control plane 9 CSN anchored mobility management based on PMIP6 is transparent to the MS. At the t ime of the network entry, 10 MS u ndergoes t he r egular at tachment p rocedures without directly p articipating i n mobility s ignaling; s elects t he 11 network, p erforms t he ne twork e ntry a nd p roceeds b y c onfiguring t he I P a ddress. F or a gi ven M S, t he network 12 determines whether to use PMIP6 or not. 13

The P MIP6 co ntrol p lane an d s ignaling l egs ar e s hown i n Figure 7-98. E xplicit P MIP6 s ignaling o ccurs o nly 14 between the MAG and LMA functions. When MAG and LMA are interconnected by the IPv4-based infrastructure, 15 the IPv4 transport mechanism described in [100] is used to carry the signaling messages over the R3/R5. 16

• Upon successful authentication and authorization, the MAG initiates PMIP6 registration with the assigned 17 LMA, providing the Proxy-CoA, user’s NAI, and other parameters needed to set up the forwarding path in 18 the PBU message. The LMA assigns (allocates, if requested by the MAG) the IPv6 HNP and/or IPv4 Home 19 Address and acknowledges the registration by replying with the PBA. 20

• Upon r eceiving the P BA from t he LMA, t he M AG sends a R outer Advertisement t o t he M S with t he 21 assigned IPv6 prefix. In case of IPv4, the MAG performs the DHCP procedures as per [100] to convey the 22 IPv4 address to the MS. 23

• After t he MS acq uires t he I Pv6 h ome ad dress/network p refix t he MS may i nitiate s tateful I Pv6 ad dress 24 configuration using DHCPv6 as per [99]. 25

802.16 PHY

802.16 MAC

CS

IPv6 [IPv4]

802.16 PHY

802.16 MAC

CS

PHY

L2 / Intra ASN Data Path

MS BS

PHY

IPv6 [IPv4]


PHY

IPv6 / IPv4

L2

PHY

IPv6 / IPv4

PMIPv6PMIPv6

L2

MAG LMA

R1 R6 R3/R5

26

Figure 7-98 - PMIP6 control plane 27

PMIP6 enables IPv6 hosts to sustain the IP connectivity in case of R3 relocation. Additional protocol extension adds 28 in mobility management capabilities for IPv4 hosts as well. The data plane for PMIP6 is illustrated in Figure 7-99 29 (PMIP6 support for IPv4 mobility shown in square brackets). 30

After a ttachment o r r elocation, th e M AG a llocated a t th e ASN-GW/ASN r egisters its P roxy-CoA cr eating o r 31 updating the binding entry at the LMA, thus redirecting the forwarding path towards MS’s current location. The 32 MAG is always located on the MS’s data path. The R3 tunnel between MAG and LMA SHALL support IPv4 or 33 IPv6 transport mechanism. The R3 PMIP6 tunnel SHALL be per HNP and IPv4 address for each MS. The transport 34


Page - 201


tunnel setup over the R3 SHOULD be discovered and established in a dynamic manner, using the following payload 1 transport methods: 2

• GRE key exchange and transport for PMIP6 as specified [101] 3

• One of IPv6-based encapsulation specified in [99] 4

• One of IPv4-based encapsulation method specified in [100] 5

802.16 PHY

802.16 MAC

CS

IPv6 [IPv4]

802.16 PHY

802.16 MAC

CS

PHY


MS BS

PHY

IPv6 [IPv4]


PHY

GRE / IPv6 / IPv4

L2

PHY

GRE / IPv6 / IPv4

IPv6 [IPv4]IPv6 [IPv4]

L2

MAG LMA

PHY

IPv6 [IPv4]

L2

CN

R1 R6 R3

6

Figure 7-99 - Data plane with PMIP6 7

7.8.4.5 IPv4 support 8 In o rder to f ully c omply with I ETF P MIP6 s pecifications, W iMAX® network S HALL i mplement I Pv4 mobility 9 support as given in [100]. The scope of IPv4 support in PMIP6 includes 2 separate aspects: 10

• Mobility support for IPv4 hosts. T his includes acquisition and provision of the IPv4 address, appropriate 11 handling of mobility bi ndings, r outing e ntries a nd de fault r outer s ettings, a s to e nable I Pv4 M S t o r oam 12 within the PMIP6 domain maintaining its IPv4-MN-HoA. 13

• Mechanisms for transport of user payload and PMIP6 signaling over the IPv4-based network infrastructure 14 SHALL be supported in WiMAX. This requires at least one of GRE, native IPv4 encapsulation, IPv4-UDP 15 or IP v4-UDP-TLV en capsulation methods t o b e s upported o ver t he R 3 r eference p oint. I f a W iMAX 16 network supports PMIP4 protocol in addition to PMIP6, the IPv4 mobility support in the ASN SHALL be 17 activated i n acco rdance with n etwork’s I P s ervice s election an d authorization d irective as d escribed i n 18 section 7.3.11. The IPv4 transport over R3 as well as IPv4 mobility for the MS are dynamically negotiated 19 between the ASN and CSN during the network authentication procedure, as part of IP service selection. 20

The IPv4 support capabilities SHALL be indicated and authorized separately between the ASN and CSN as part of 21 network authentication process and IP service authorization. 22

7.8.4.6 Additional considerations 23 7.8.4.6.1 Link model implications 24

PMIP6 ach ieves t he mobility s upport b y e mulating t he h ome l ink co nfiguration o n t he acces s l inks where M S 25 attaches within the d omain. Proper p rotocol operation relies o n a p oint-to-point link model between the M S and 26 MAG. Conventional deployment model for this interface in WiMAX includes R1 interface and L2 tunnel over the 27 R6 reference point, as well as L2 tunnel over the R4 interface, already satisfying such point-to-point link model 28 requirement. 29

Furthermore, PMIP6 avoids complexity of distributed IP links and neighbor reachability issues by restricting the 30 IPv6 prefix delegation model and assigning a g lobally unique prefix per MS. This way the MS and MAG form a 31 virtual home link which no other node is sharing. PMIP6 feature in WiMAX SHALL NOT make use of shared/64 32 prefixes for MN-HoA configuration. 33

7.8.5.6.2 Multihoming 34

Although s upported by P MIP6 protocol [ 99], c onsiderations on multihoming scenarios, u se a nd h andovers o f 35 multiple interfaces from a single MS are not in scope of this release. 36


Page - 202


7.8.4.6.3 Home link emulation 1

For t he a ssociated M S r unning o n P MIP6 s ervice the ne twork ne eds t o maintain t he ho me l ink e nvironment 2 throughout a ll M S p oint-of-attachment ch anges. M echanisms en abling t his ap pearance i nclude co nfiguration o f 3 default IP router information at the serving AR/MAG achieved through dynamic distribution via PMIP6 signaling as 4 described in [99] and [100]. Similar requirement applies for provisioning of other network service information such 5 as DNS or DHCP settings that need to be kept consistent after the L3 handover. 6

7.8.4.7 PMIP6 connection setup procedure 7 As s hown i n Figure 7-100, PMIP6 co nnection s etup t akes p lace af ter t he i nitial n etwork e ntry co mpletes. T he 8 mobility b inding r egistration f rom the AR/MAG c an o ccur a t a ny moment following th e a ccess a uthentication 9 response that brought the required IP capabilities and services authorization from the H/VCSN to the ASN where 10 MS is attaching. 11

Depending o n the n etwork’s IP ca pabilities an d local p olicy IPv6 MSs may use ei ther stateless ad dress 12 autoconfiguration or s tateful address configuration mode via DHCP Proxy/Relay. The IPv4 MS uses DHCPv4 to 13 obtain its IPv4 MN-HoA address. 14

Definition of triggers and decision mechanisms for the ASN, in particular when multiple IP services are authorized, 15 is implementation specific. 16

LMABSIPv4/v6MS

DHCPServer

HoA config request (SLAAC, DHCPv4/v6)

ISF Establishment

PMIPv6 PBU/PBA

HoA config completion

MAG

HoA config completion

AAA

802.16e INE and NW Authentication Procedure

AAA query

17

Figure 7-100 - PMIP6 connection setup principles 18

7.8.4.8 PMIP6 session renewal 19 PMIP6 s ession r enewal c orresponds t o t he b inding l ifetime e xtension when t here i s no r elated ha ndover e vent. 20 Before t he e xpiry of M S’s P MIP6 b inding the AR/MAG sends the Proxy Binding U pdate (PBU) with the same 21 Proxy-CoA source a ddress a s i n i nitial b inding r egistration a nd no n-zero l ifetime t o renew the I P s ession an d 22 binding entry at the LMA. Upon receiving such a PBU the LMA refreshes the MS’s binding cache entry and, if 23 applicable, extends lifetime of the dynamic forwarding tunnel established for the specific MS. 24

The renewal of MS’s HNP/MN-HoA SHOULD be managed appropriately to decouple the process from the actual 25 IP session renewal. 26

7.8.4.9 PMIP6 CSN-anchored mobility handover 27 As s hown in Figure 7-101, PMIP6 m obility h andover co mes as a r esult o f t he A-DPF ha ndover a nd R 3 p ath 28 relocation t o t he new serving A SN. I f n ot p erformed d uring t he I dle Mo de, t he p rocess i s proceeded b y r egular 29 ASN-MM procedures where the PMIP6 MAG remains anchored at the previous serving ASN-GW/ASN(a) until the 30 Push/Pull A -DPF HO is triggered. In course of the process the new ASN-GW/ASN(b) o btains a ll mobility- and 31


Page - 203


security w ise session information from the serving A SN(a) and Anchor Authenticator, and is able to register the 1 MS’s new location at the LMA. Successful PMIP6 registration from the new MAG (new Proxy CoA) results with a 2 refresh to binding cache at the LMA, extension to MS’s PMIP6 session and an update to MS’s forwarding tunnel 3 now redirected towards the new serving MAG at the ASN(b). 4

ASN(b)MAGBSIPv4/v6

MSASN(a)MAG LMA

PMIPv6 session and data path established

ASN-MM procedures

A-DPF handover

PMIPv6 PBU/PBA

New PMIPv6 data path and IP session extended

A-DPF HO completion

Authenticator

HO indication [Key]

5

Figure 7-101 - PMIP6 mobility handover principles 6


Page - 204


7.8.4.10 PMIP6 session termination 1 As shown in Figure 7-102, the PMIP6 session termination may happen for a number of reasons that can be split in 2 two categories: 3

• MS-initiated termination (either graceful or ungraceful, dependant if DREG-REQ is sent). 4

• Network-initiated termination (ASN-GW/A-DPF-, LMA-, or AAA triggered) 5

MS self-initiates PMIP6 session termination when detaching from the network with graceful network exit, or simply 6 performing the IP/DHCP release procedure for its IP session. The designated network entities may also initiate the 7 IP session termination if discovering the MS has detached/lost connectivity, prohibited from continuing the service 8 or for some o ther operative o r administrative reason. The ASN-GW/A-DPF, LMA or t he AAA server i nduce t he 9 path d eregistration b y i ssuing a co rresponding t rigger m essage t owards t he s erving ASN-GW/ASN. S ession 10 termination SHALL follow the common WiMAX Forum® Network Architecture procedures and signaling exchange 11 to ach ieve R4/R6 p ath release, MS s tate change and acco unting stop. I f ap plicable, t he network-initiated s ession 12 termination SHALL include PMIP6 De-registration at the LMA as well as IP/DHCP release on the MS side. 13

Auth.BSIPv4/v6MS

ASN(MAG) LMA

PMIPv6 De-registration

DREG, L3 Release

AAA

Network-initated terminationMS-initiated termination

Data path release

Accounting Stop

14

Figure 7-102 - PMIP6 session termination principles 15

7.8.4.11 PMIP6 session authentication and authorization 16 The PMIP6 s ession authentication and authorization is compliant to the general IP service selection and 17 authorization framework described in section 7.3.11: 18

First, the PMIP6 service is authorized by the HCSN/HAAA. The HAAA SHALL provide the information of th e 19 assigned LMA entity (the IP service anchoring MAY be possible in HCSN, or VCSN when MS is roaming). 20

The PMIP6 service specifics such as IPv4 host mobility and transport and signaling protection method SHALL be 21 negotiated explicitly a s part of t he IP service authorization. Bootstrapping o f required security parameters and IP 22 configuration parameters (if available) from the HCSN/HAAA to the requesting ASN SHALL take place 23 simultaneously as part of the same process. 24


Page - 205


7.9 Radio Resource Management 1

7.9.1 Functional Requirements 2 The functional requirements for Radio Resource Management are: 3

a) RRM s pecification S HALL be b ased o n a g eneric ar chitecture t hat e nables e fficient r adio r esource 4 utilization in a WiMAX® network. 5

b) Generic architecture implies that while RRM implementations MAY assist several other WiMAX network 6 functions that impact available radio resources at any given time (QoS, Service Flow Admission Control, 7 mobility management, ne twork management, e tc.), t he RRM f unctionality i tself M AY b e s pecified 8 independent of any such functions that RRM assists as long as inter-vendor interoperability is not affected. 9

c) RRM specification SHALL define mechanisms and procedures to share radio resource related information 10 between ASN network entities (e.g., BS or ASN-GW). Examples of such information include wireless link 11 capability or available spare capacity in a BS. 12

d) RRM procedures SHALL a llow for different B Ss to co mmunicate, in a standardized manner, with eac h 13 other or with a ce ntralized RRM entity residing in the same or a d ifferent ASN to exchange information 14 related to measurement and management of radio resources. 15

e) Each B S S HALL p erform r adio r esource m easurement l ocally b etween i tself an d t he population o f M S 16 served by it, as per IEEE 802.16 specifications. Procedures for such measurements SHALL remain out of 17 the scope of WiMAX Forum® Network Architecture specifications, even though such measurements MAY 18 be used as a basis for radio resource allocation and reconfiguration decisions by ASN network entities (e.g., 19 BS or ASN-GW). 20

f) It SHALL be possible to deploy RRM in an ASN using Base Stations that have no direct communication 21 between them. 22

g) It SHALL be possible to deploy RRM in an ASN using Base Stations that support direct communication 23 between them. 24

g) It SHALL be possible to deploy RRM in an ASN using Base Stations with RRM function as well as a 25 centralized R RM e ntity t hat d oes n ot r eside i n t he B S, an d t hat co llects an d updates r adio r esource 26 indicators from several BSs in a standardized way. These indicators SHOULD be sufficient to provide the 27 required information for making such decisions as choice of Target BS, admission or rejection of Service 28 Flows, et c. T he f requency of s uch co llections M AY b e d ependent o n a vendor/operator’s s pecific 29 requirements. The content of such collections, however, SHALL be specified. 30

h) The architecture SHALL allow a BS to learn about neighboring BSs using: 31

o Static configuration data (e.g., existence of neighboring BSs). 32

o dynamically collecting radio resource indicators from other BSs, either directly, or indirectly by help 33 of an RRM entity in the ASN that is aware of dynamic load situation of neighboring BSs. 34

RRM pr ocedures M AY pr ovide de cision s upport f or on e or m ore of t he f ollowing W iMAX network f unctions. 35 However, RRM specification SHALL NOT be t ied to any one o f t he following functions a s long as inter-vendor 36 interoperability is not affected: 37

a) MS Admission Control and Connection Admission Control - i.e., ascertaining a p riori that required radio 38 resources are available at a potential target BS before handover. 39

b) Service Flow Admission Control - i.e., creation or modification of existing/additional service flows for an 40 existing MS in the network. Selection of values for Admitted and Active QoS parameter sets for Service 41 Flows. 42

c) Load C ontrol - manages situation where s ystem l oad ex ceeds t he threshold an d s ome counter-measures 43 have to be taken to get the system back to feasible load. 44


Page - 206


d) Handover preparation and Control - for improvement/maintenance o f overall performance indicators ( for 1 example, RRM M AY a ssist in s ystem lo ad b alancing b y f acilitating s election o f t he most s uitable B S 2 during a handover). 3

e) RRM procedures SHALL only specify the interfaces (i.e., protocols and procedures) between functional 4 RRM entities residing in BS or outside BS (e.g., a centralized RRM entity in ASN-GW or elsewhere). Any 5 interfaces between these RRM entities and other control entities in ASN (e.g., QoS, session management, 6 etc.), while feasible, SHALL be outside the scope of RRM specification. 7

In some ASN function split profiles, an RRM entity and the said other control entities that MAY benefit from RRM 8 data are collocated in the same logical component (e.g., BS or ASN-GW), so the information exchange be tween 9 them is internal communication. 10

a) RRM communication procedures SHALL be interoperable and compliant with IEEE standards. 11

b) RRM c ommunication pr ocedures S HALL pr ovide for in teroperability b etween B S, A SN-GW, o r o ther 12 ASN network elements from different vendors. 13

7.9.2 Functional Decomposition 14

7.9.2.1 Functional Entities 15 RRM is composed of RRA and RRC from signaling transaction perspective as follows: 16

a) Radio R esource Agent (RRA) - This functional entity resides in BS and each BS shall have an RRA. It 17 maintains a database of collected radio resource indicators. An RRA is responsible for assisting local Radio 18 Resource Management (RRM) as well as communicating to the RRC, if present, including for example: 19

o Collection/Measurement of radio resource indicators from the BS. 20

o Collection/Measurement of radio resource indicators from the population of MS registered to the BS, 21 using M AC management pr ocedures a s pe r I EEE 802.16 s pecifications a nd ot her m easurement 22 reporting for upper layers (e.g., derived bit error rate, MAC PDU error rate). 23

o Communicating R RM co ntrol i nformation o ver t he ai r i nterface t o M S, as p er I EEE 8 02.16 24 specifications. An e xample of s uch R RM c ontrol in formation i s s et o f n eighbor B Ss a nd t heir 25 parameters. 26

o Signaling procedure exchange with RRC for radio resource management function. 27

o Controlling t he r adio r esources o f t he r espective B S, b ased o n t he measurements p erformed a nd 28 measurement reports received by the BS and based on information received from the RRC functional 29 entity if available. This local resource control includes power control, supervising the MAC and PHY 30 functions, modifying t he c ontents o f t he M OB_NBR-ADV br oadcast m essage ( by help of 31 information from RRC or from management system), assisting the local Service Flow Management 32 (SFM) function and policy management for Service Flow admission control, making determinations 33 and conducting actions based on radio resource policy, assisting the local HO functions for initiating 34 HO etc. 35

h) Radio Resource Controller (RRC) - This optional functional entity MAY reside in BS (one per BS), 36 in ASN-GW, or, as a standalone server in an ASN. The RRC MAY be collocated with RRA in the BS, or 37 separate. In the former case, the interface between RRC and RRA is out of the scope of this specification. 38 Such RRC MAY also communicate with RRCs in neighboring BSs which may be in the same or different 39 ASN. In the latter case, RRC MAY reside in the ASN-GW (or as a s tandalone server) communicating to 40 RRAs acr oss R6 r eference p oint. W hen R RCs ar e p resent i n ASN, each RRA s hall b e as sociated with 41 exactly one RRC. On the other hand an RRC may be associated with zero, one or more RRAs in the same 42 ASN. An RRC is responsible for: 43

o Collection of radio resource indicators from associated RRA(s): When RRA is collocated with RRC 44 in the same BS, the interface between RRA and RRC is outside the scope of this specification. When 45 RRA(s) and RRC are separated across R6 reference point, the collection of radio resource indicators 46 SHALL be as per primitives and information reporting procedures defined in this specification. 47


Page - 207


o Communication b etween/across R RCs: An R RC M AY co mmunicate with o ther R RCs acr oss 1 WiMAX Forum® Network Architecture-specified interfaces. 2

i) RRC Re lay - This f unctional e ntity M AY r eside in ASN-GW f or t he pu rpose of r elaying RRM 3 messages. R RC Relay can not t erminate R RM messages b ut i t o nly r elays these t o t he f inal d estination 4 RRC. 5

When RRC is collocated with the BS, RRCs in different BSs SHALL communicate through the RRC Relays located 6 in the ASN-GWs when there is no R8 interface. If the R8 is exist, RRCs in different BSs may communicate through 7 the R8 interface. 8 When RRC resides in ASN as a standalone server or in ASN-GW, RRCs MAY communicate across R4 reference 9 point. 10

Standardized RRM procedures are required between RRA and RRC, and between RRCs across WiMAX Forum® 11 Network Architecture-specified interfaces. These procedures are classified into two types: 12

• Information Reporting Procedures for delivery of BS radio resource indicators from RRA to RRC, and 13 between RRCs. 14

• Decision Support Procedures from RRC to RRA for communicating suggestions or hints of aggregated 15 RRM status (e.g., in neighboring BSs) for various purposes. 16

7.9.2.2 RRM Generic Reference Models 17 RRM reference model MAY take one of the following two forms as follows: 18

Generic Reference Model #1 is shown in Figure 7-103. 19

RRC RRC

RRA

BS1RRA

BS2

RRA

BS3

RRA

BS4

R6 R6

R6R6

R4ASN-GW#1

ASN-GW#2

20

Figure 7-103 - RRAs Resident in BS and RRC Resident in ASN 21

The above reference model is based on RRA in each BS and RRC resident outside BS in the ASN. RRAs and RRC 22 interact across R6 reference point, using two types of procedures visible at WiMAX Forum® Network Architecture 23 specified open interfaces -information reporting procedures (dashed lines) and decision support procedures (solid 24 lines). RRCs MAY communicate with each other using R4 reference point. 25

Generic Reference Model #2 is shown in Figure 7-104. 26


Page - 208


RRCRelay

RRCRelay

RRC

RRA RRC RRC

RRC

RRA

RRA RRABS1

R6

R6R6

R6

BS4

BS3BS2

R4ASN-GW#2

ASN-GW#1

1

Figure 7-104 - RRA and RRC Collocated in BS 2

The above reference model is based on collocated RRA and RRC in each BS. The interface between RRA and RRC 3 is o utside t he scope o f t his s pecification. W e i ntroduce t he “R RC R elay” i n t he ASN to en able t he RRC-RRC 4 communication within and between ASNs over the standard reference interfaces. RRC Relay resides in the ASN 5 GW and acts as a relay for the RRM messages. 6

Note: this reference model is based on the assumption that there is no R8 reference point, which may be used for 7 direct communication between BSes. 8

The above two generic reference models can be mapped to the ASN reference model and ASN entities. 9

7.9.3 Primitives 10 RRM primitives MAY be used either to report radio resource indicators (i.e., from RRA to RRC, or, between RRCs) 11 or, to communicate decision support information (i.e., from RRC to RRA). The former type of primitive is called 12 information reporting primitive and the latter is called decision support primitive. 13

The following information reporting procedures SHALL be supported: 14

a) Per -BS Spare Capacity Repor ting procedure - These reports are indexed by BS ID and indicate the radio 15 resources available at the BS (BS-ID refers to a sector with a s ingle frequency assignment), e.g. as a hint 16 for B ase S tation selection d uring network e ntry or handover. S uch r eporting M AY be s olicited or 17 unsolicited. S uch r eports S HALL b e s ent from R RA t o RRC as well a s b etween R RCs s uch t hat al l 18 interested RRCs MAY have available information on current spare capacity of the BS for which they are 19 responsible, or , of neighboring BSs. Note that this report does not refer to the service requirements o f a 20 specific MS and hence is not a r eplacement of t he “HO_Req and HO_Rsp” specified for the Intra-ASN 21 Handover preparation phase. 22

b) Per MS P HY Service L evel R epor ting p rocedure These reports are indexed by MS. Such reporting is 23 always solicited by RRC. Such reports SHALL be sent from RRA to RRC to update the per-MS databases 24 in the RRC. These reports SHALL be generated for MS registered with the BS that is associated with the 25 RRC. (See section 7.9.4.3 - Per-MS PHY Measurement Solicitation and Report.) 26


Page - 209


The following decision support procedures SHALL be supported: 1

j) Neighbor BS radio resource status update These reports are delivered from RRC to RRA to propose 2 a change of the broadcasted advertising message. (See section 7.9.4.4 - Neighbor BS Radio Resource Status 3 Update.) 4

Corresponding to these information reporting and decision support procedures, the corresponding RRM primitives 5 are listed in Table 7-4. 6

Table 7-4 - Primitives for RRM 7

Name Source Destination Purpose Reporting or Decision support

RRM PHY_Parameters_Req RRC RRA Request for PHY_Parameters_Rpt, per MS.

Request reports from RRA

RRM PHY_Parameters_Rpt RRA RRC Assessment of link level quality per MS.

Reporting from RRA to RRC

RRM Spare_Capacity_Req RRC RRA/RRC Request for Spare_Capacity_Rpt per BS.

Request reports from RRA;

Request reports from RRC

RRM-Spare-capacity-report RRA/RRC RRC Available Radio Resource report per BS.

Reporting from RRA to RRC;

Reporting between RRCs

RRM-Neighbor-BS radio resource status update

RRC RRA Update the broadcasted Neighbor BS list

Decision support

RRM-Radio-configuration-request

RRC RRA/RRC Request for Spare_Capacity_Rpt per BS.

Request reports from RRA;

Request reports from RRC

RRM-Radio-configuration-report RRA/RRC RRC Available Radio Resource report per BS.

Reporting from RRA to RRC;

Reporting between RRCs

8

Note: The final set of RRM procedures is defined in the Stage-3 Specification. 9

7.9.4 Procedures 10 This subsection describes the protocol primitives at a functional level: 11

• Request for per-BS Spare_Capacity_Rpt 12

• Per-BS Spare_Capacity_Rpt 13

• Request for per-MS PHY measurement report 14

• Per-MS PHY measurement report 15

• Neighbor BS radio resource status update 16

Note: The final set of RRM procedures is defined in the Stage-3 Specification. 17


Page - 210


7.9.4.1 Request for Spare_Capacity_Rpt 1 This primitive can be applied by an RRC to request a Per-BS Spare_Capacity_Rpt from an RRA or from another 2 RRC. 3

An RRC SHALL send this request whenever to query spare capacity in a BS. 4

The RRC MAY send this request periodically or at any time. The RRC M AY also send this request based on a 5 network event trigger. 6

RRA or RRC RRC

Spare_Capacity_Req(reporting characteristics)

7

Figure 7-105 - Request for Spare_Capacity_Rpt, per BS 8

Reporting characteristics: Indicates whether report SHOULD be sent periodically, or event-driven etc. The detailed 9 list of events is given in the Stage-3 Specification: 10

7.9.4.2 Per-BS Spare_Capacity_Rpt 11 RRA (RRC) SHALL send the following type of report to RRC: 12

Spare_Capacity_Rpt which in cludes th e “Available Radio R esource” i ndicator ( percentage o f r eported av erage 13 available sub-channels and symbols resources per frame. The average is over a co nfigurable interval with a d efault 14 value of 200 frames). 15

RRA or RRC RRC

Spare_Capacity_Rpt(Spare capacity indicator)

16

Figure 7-106 - Spare_Capacity_Rpt, per BS (Unsolicited or Solicited) 17

The r eport M AY b e s ent p eriodically o r ev ent-driven. The d etailed lis t o f e vents is g iven in the Stage-3 18 Specification. 19

A t abular r epresentation o f t he S pare Capacity Reporting p rimitive r eporting the “Available R adio R esource” 20 indicator is given in the Stage-3 Specification. 21

DL (UL) Available Radio Resource: 22

As defined in [80], Available DL or UL Radio Resource indicators SHALL indicate the available radio resources for 23 each direction. These are the average ratios of non-assigned DL or UL resources to the total usable DL or UL radio 24 resources. The averaging SHALL take place over a configurable time interval with a default value of 200 frame. 25


Page - 211


7.9.4.2.1 Usage Scenarios 1 The “A vailable r adio r esource” measurements p rovided b y t he RRAs t o R RC M AY be u sed b y RRC for l oad 2 balancing: A p otential s trategy o f RRC M AY b e to in teract with th e H O c ontroller w ith t he o bjective to h ave 3 approximately equal load, as expressed by the “available resource indicator”, in all BSs controlled by RRC – subject 4 to the availability of suitably radio path conditions between a MS and the potential HO target BSs. 5

The “available radio resource” indicator SHALL be determined by the BSs as specified above. 6

Possible ways o f R RM interaction with th e H O d ecisions h ave b een d escribed i n WiMAX F orum® Network 7 Architecture Stage-2 specification; Section 7.7 - ASN Anchored Mobility Management and 7.8 - CSN Anchored 8 Mobility Management. In Network Initiated Handoff as well as in MS Initiated Handoff, the ASN uses Handover 9 Request p rimitive to co mmunicate with a number o f candidate BSs for permission to handoff a MS or MS’. The 10 candidate BS list MAY be recommended or modified by the external module such as RRC. 11

7.9.4.3 Per-MS PHY Measurement Solicitation and Report 12 This primitive can be applied by an RRA to report to an RRC, or by an RRC to report to another RRC. 13

RRC MAY use this primitive exchange once it has received a HO_Req from Serving BS to learn (or recollect a 14 more updated set of parameters) regarding the MS PHY service levels for the Serving BS and each candidate BS. In 15 addition, RRC MAY check the latest “Spare capacity report” whether capacity is available for adding the MS, and 16 RRC will return the updated list of candidate BSs to Serving BS. 17

RRA/RRC RRC

PHY_Parameters_Req (MS_ID)

PHY_Parameters_Rpt (MS_ID, DL PHYService Level, UL PHY Service Level, etc.)

18

Figure 7-107 - PHY Report (Solicited) 19

As per this primitive exchange, the BS SHALL send the following types of reports to RRC: 20

PHY repor ts for DL & UL per MS. These reports include the set of parameters described in Section 8.4.11 of [1]. 21 Additionally, these reports include the PHY feedback parameters (on a per-MS basis). All parameters are encoded in 22 TLVs. 23

DL parameters are measured by MS and reported by BS to RRC. UL parameters are measured and reported by BS to 24 RRC. Same parameters MAY be reported from one RRC to another. 25

A tabular representation of the PHY Report primitive is given in the Stage-3 Specification. 26

In case the RRC is collocated with Target HO Function, it MAY be possible to include these measurement reports 27 into the Handover-Request messages or HO_Rsp messages sent from BS to the HO Control. This is FFS. 28

In order to meet a Stage-1 Requirement for channel quality monitoring, this message might be augmented to include 29 measurements related to QoS parameters, e.g., “burst error rate”. – To be checked during work at Stage-3. 30

7.9.4.4 Neighbor BS Radio Resource Status Update 31 This procedure can be used by RRC to inform a Serving BS about the list of Neighbor BSs which are potential HO 32 Target Base Stations for any MS being served by the SBS, including information about their radio resource status. It 33 is important consideration for the serving RRC to synchronize the radio resource information that are received from 34


Page - 212


the RRAs of the neighbor BSs as well as from other RRCs to provide the accurate and up-to-date information to the 1 RRA of the Serving BS in order to allow the MS to make appropriate HO decision. The policy on the information 2 processing at the RRC and the frequency of the status update is outside the scope of this specification. 3

RRA ( in SBS) MAY use this hint from RRC as a basis for updating the Neighbor BS Advertisement: SBS would 4 ask the MS to trigger the scanning of the respective neighbor BSs, by means of MOB_NBR_ADV. 5

RRA RRC

Neighbor_BS_Resource_Status_Update(Neighbor BS list)

6

Figure 7-108 - Neighbor BS Radio Resource Status Update Procedure 7

A tabular representation of the RRM-Neighbor-BS-Radio-Resource-Status-Update primitive is given in the Stage-3 8 Specification. The primitive has been suitably adopted from MOB_NBR-ADV message format, as defined in [2] 9 and amended by [80]. 10

7.9.5 Power Management and Interference Control 11 In this release, power management and interference control is primarily a t ask performed by each BS. In addition 12 there i s a n RRM p rimitive “RRM PHY_Parameters_Rpt”, s ee ab ove, f or i nterference measurement r eport from 13 RRA to RRC to allow RRC to get involved in interference control. 14

Power management during idle mode and sleep mode is handled elsewhere in the Stage-2 document. 15

Potential enhancements of power management and interference control, as well as of RRM in general, are for further 16 study. 17

Future e nhancements o f R RM MAY in clude a dding R RM p rimitives f or th e following a pplications th at a re 18 considered t o be s olved in th is r elease locally b y t he B S S ite, or t o be l eft t o B S configuration or N etwork 19 Management: 20

• Reconfiguration of sub-channel space to be used in a BS (sector). 21

• Reconfiguration of maximum transmit power of a BS. 22

• Reconfiguration of burst selection rules. 23

• Reconfiguration of radio resource allocation and scheduling policies in a BS. 24

• Reconfiguration of UL/DL switching point for TDD. 25

• Reconfiguration of broadcast information (e.g. supported burst profiles). 26

• Forwarding of DCD and UCD information between neighboring base stations. 27

7.10 Paging and Idle-mode MS Operation 28

7.10.1 Functional requirements 29 The following functional requirements SHALL be supported in the WiMAX® network: 30

a) Paging f eatures s hould b e s upported i n N omadicity a nd P ortability u sage models whereas t hey ar e 31 mandatory for Full Mobility usage scenario (see Stage 1 document). These features shall be compliant 32 with IEEE 802.16e. 33


Page - 213


k) Paging G roups, a s d efined i n I EEE Std 802.16e, s hall co mprise a s et o f B ase S tations. An acces s 1 network ( i.e., N AP) m ay be pr ovisioned t o c onsist o f on e or more P aging G roups. A N AP may 2 comprise on e or more P aging Controllers. E ach I dle MS i n t he NAP i s a ssigned a s ingle P aging 3 Controller, called Anchor PC. 4

l) An MS in idle mode must be accessible in the network during Paging Intervals for Paging and Location 5 Updates. This covers cases where the MS: 6

(1) stays in the coverage area of same BS in the access network or, 7

(2) moves to the coverage area of a new BS (in the same or different Paging Group) in the access 8 network. 9

7.10.2 Functional Decomposition 10 The Paging operation shall comprise the following functional entities: 11

Paging Controller (PC) - Paging controller is a functional entity that administers the activity of idle mode MS in 12 the network. It is identified by PC ID (6 bytes) in IEEE Std 802.16e, which could map to the address of a functional 13 entity in WiMAX Forum® Network Architecture. The PC MAY be either co-located with BS or separated from BS 14 across R6 reference point. There are two types of PCs: 15

o Anchor PC: For each idle mode MS, there shall be a single Anchor PC that contains the updated 16 location information of the MS. 17

o Relay P C: T here may al so be o ne o r more o ther P Cs i n t he n etwork ( called R elay P C) t hat 18 participate in relaying Paging and Location Management messages between PA and the Anchor 19 PC. 20

Paging Agent (PA) - Paging Agent is a functional entity that handles the interaction between PC and IEEE Std 21 802.16e specified Paging related functionality implemented in the Base Station. A Paging Agent is co-located with 22 BS. The interaction between PA and Base Station is out of scope of WiMAX Forum® Network Architecture. When 23 the P A i s l ocated acr oss R6 reference p oint from the P C, its in teraction with P C is within t he scope o f N WG 24 specification. However, when PC is also co-located with BS, the interaction between the co-located PA and PC is 25 outside the scope of WiMAX Forum® Network Architecture. 26

Paging Group (PG), defined in IEEE Std 802.16e, may be interpreted as comprising one or more Paging Agents. A 27 Paging Group resides entirely within a NAP boundary. Paging Groups are managed by the network management 28 system and p rovisioned per the access network operator’s provisioning requirements. Paging Group management 29 and its provisioning requirements are not in scope of this document. 30

Location R egister ( LR) - An LR i s a d istributed d atabase with eac h i nstance co rresponding t o an Anchor P C. 31 Location r egisters c ontain i nformation a bout I dle mode M Ss. T he i nformation f or e ach M S i ncludes, bu t i s n ot 32 limited to: 33

a) Contains MS Paging Information for each MS that has registered with the network earlier but currently 34 in Idle mode. 35

Current paging group ID (PGID) 36

PAGING_CYCLE 37

PAGING_OFFSET 38

Paging Interval Length 39

Last reported BSID 40

Last reported Relay PCID 41

m) MS Service Flow Information comprising 42

(1) Idle Mode retention information for each MS in idle-mode 43

(2) Service Flow Information for each MS 44


Page - 214


An instance of a Location Register is associated with every Anchor PC. Specifying communication between LR and 1 PC is outside the scope of this specification. 2

PA2 PA4 PA5 PA6

PC

LR LR

PC

Paging Group CPaging Group BPaging Group A

Note 1: When PC is co-located with BS, the interface between PA and PC is outside NWG scope. When PC is notco-located with BS, the interface between PA and PC is across R6 reference point, and in NWG scope.

Note 2: From MS perspective, PCs shown above may behave as Anchor PC or Relay PC. Each idle mode MS hasone Anchor PC and may have one or more relay PCs to communicate with anchor PC.

R4

PA1PA0

3

Figure 7-109 - Paging Network Reference Model 4

The following points are noteworthy regarding this reference model: 5

a) There MA Y b e m ultiple P Gs i nside an o perator’s ( i.e., N AP) n etwork d omain. T o k eep P aging 6 functionality o ptimally i mplemented ( i.e., p revent P aging G roups f rom b ecoming to o la rge), multiple 7 Paging G roups shall b e a llowed i n t he network. Figure 7-109 specifies P aging G roups i n r eference to 8 WiMAX network reference model. A BS (and its corresponding, co-located PA) may be part of more than 9 one Paging Group. 10

n) IEEE Std 802.16e specifies PC to be co-located with e ither BS o r a separate entity i n the ne twork. T his 11 specification describes Paging related control protocol and messages between PA and PC. For the former 12 deployment scenario (where PC is co-located with BS), the messages between these co-located entities (PA 13 and P C) a re n ot e xposed ov er an WiMAX F orum® Network A rchitecture specified r eference p oint, an d 14 therefore not a consideration for interoperability. For the latter deployment scenario (where PC is not co-15 located with BS), Paging control protocol (messages) are exchanged over R6 reference point between PA 16 and PC. In both deployment scenarios, Paging Control messages between PCs are exchanged across R4 17 reference point. 18

The L ocation Register ( LR) co mprises a l ocation d atabase i n t he network. T his d atabase, acces sible 19 by/through PC, tracks the current Paging Group (identified by Paging Group ID, PGID) of each idle-mode 20 MS in the network. It also stores the context information required for Paging. In the event of MS movement 21 across Paging Groups, location update occurs across PCs via R6 and/or R4 interfaces and information is 22 updated in the LR that is associated with the Anchor PC assigned for the MS. 23


Page - 215


When MS enters IDLE mode, the LR entry for this MS is created. The LR will be updated with MS idle-1 mode retain information. For this idle-mode MS, its Anchor PC shall be either static or may change until 2 MS becomes active and performs a full network entry. 3

As MS travels in IDLE mode and crosses the boundary of it current PG, it is enforced to perform Location 4 Update. Location Update messaging between PA and Anchor PC occurs over R6 and in some cases over 5 R4 reference interfaces. R4 reference interface is involved when PA has no direct connectivity with Anchor 6 PC over R6 and, therefore, needs to reach it via intermediate routing nodes (i.e., Relay PCs). 7

NOTE 1 - For CMIP/PMIP based services, MS movements while in idle mode may not result in FA change 8 (wakeup, MIP registration etc.) 9

NOTE 2 - For Simple IP based services, when an idle mode MS location update results in full network entry (e.g., 10 unsecured location update, re-authentication), the MS PoA IP address refresh may be performed. 11

7.10.3 Paging and Idle-Mode MS Operation Procedures 12 This section describes the protocols and procedures as per the above reference model. 13

The following is a generic case that depicts an MS about to enter IDLE mode as it is served by Foreign Agent (FA) 14 /Access Router (AR) and Authenticator in the network. The downlink traffic comes from either HA or CR (Core 15 Router) in CSN. 16

Data Path FnFA/AR

Data Path Fn

BS

MS

Intra-ASN Path

R4Authenticator

R3NAP

HA

CSN

17

Figure 7-110 - Generic Depiction of Functional Entities Prior to MS Entering Idle Mode 18

When t he M S en ters I dle mode a PC en try for t he M S i s cr eated ( instantiated) an d t he b earer t unnels f or d ata 19 forwarding b etween Anchor D ata P ath F unction, an d B S ar e r emoved. N ote t hat t he ability t o s end R 4 a nd R 6 20 signaling is not impacted by the removal of the bearer tunnels. As idle mode MS moves in the network, the FA/AR 21 itself could be migrated as well but that is left as an implementation option. 22


Page - 216


HA

CSN

NAP

Authenticator

LR

Anchor PCR4 R4

Data Path FnR3

FA/AR Relay PC

BS

MS 1

Figure 7-111 - Generic Depiction of Functional Entities after MS Enters Idle Mode 2

7.10.3.1 Backbone Primitives for Paging and Idle Mode 3 Paging and Idle Mode Primitives are divided into the following two groups: 4

(1) Primitives for signaling paging control and location management 5

(2) Primitives for signaling LR updates 6

summarizes the backbone primitives, which may be communicated between PA and PC. 7

Table 7-5 - Primitives for Paging Control and Location Management “for information only, the 8 binding facts are defined in the Stage3 Specification” 9

Primitives From To

Paging_Announce Anchor PC Relay PC(s) (in PG) PAs in PG

Location Update Request PA Relay PC(s) Anchor PC

LU_Rsp Anchor PC Relay PC(s) PA

Delete_MS_Entry_Req A_DPF A_PC/LR, BS/DPF DPF/Relay PC, DPF/Relay PC A_PC/LR

LU_Cnf PA -> Relay PC(s) -> Anchor PC

Initiate_Paging_Req Data Path Fn Anchor PC


Page - 217


Primitives From To

Initiate_Paging_Rsp Anchor PC Data Path Fn

IM_Exit_State_Change_Req Data Path Fn Anchor PC

IM_Exit_State_Change_Rsp Anchor PC Data Path Fn

IM_Entry_State_Change_Req Relay PC Anchor PC

IM_Entry_State_Change_Rsp Anchor PC Relay PC

R4 Anchor PC Indication Anchor DPF/FA/AR Anchor PC / LR

R4 Anchor PC Ack Anchor PC / LR Anchor DPF/FA/AR

R4 PC Relocation Indication Current Anchor PC ASN Anchor DP/AR/ FA ASN

R4 PC Relocation Ack Anchor DP/AR / FA ASN Current Anchor PC ASN

The following backbone HO primitives (Table 7-6) can also be utilized in the paging 1 and location management for 1 idle mode MS. 2

Table 7-6 - Reuse of HO Primitives for Paging Operation 3

Primitives From To

Context_Req PA Anchor PC

Context_Rpt Anchor PC PA

Path_Reg_Req BS/DPF DPF/Relay PC

Path_Reg_Rsp DPF/Relay PC BS/DPF

Path_Reg_Ack BS/DPF DPF/Relay PC

Path_Dereg_Req BS Serving ASN

Path_Dereg_Rsp Serving ASN BS

Path_Dereg_Ack BS Serving ASN

CMAC Update Serving ASN Authenticator


Page - 218


CMAC Update Ack Authenticator Serving ASN

7.10.3.2 Procedures for Paging the MS and MS Exiting IDLE mode 1 Paging_Announce occurs under several scenarios which include: 2

a) Data arriving for the MS at the Anchor DPF. 3

b) Location update forced by the network for this MS. 4

c) MS re-entry into the network as forced by the network. 5

d) Cancel Paging_Announce once the MS has exited IDLE state. 6

In scenario a), when Data arrives at the anchor DPF (which may be collocated with the FA/AR as in Figure 7-112) 7 for th e M S, th us tr iggering a Paging_Announce, t he Paging c ontext i nformation ( including P GID, R elay P CID, 8 BSID, etc.) would be retrieved from LR associated with Anchor PC for the MS. The anchor PC may issue one or 9 more Paging_Announce messages based on whatever knowledge it has of the topology of the paging group for the 10 MS. Figure 7-112 illustrates the procedure for MS Paging upon receipt of downlink data for the MS. 11

6

Relay PCsmay furtherforward msgto other relay

PCs

5

4b

4a

3

1

2

Paging_Announce(to one or more Relay PCs)

Paging_Announce(to applicable PA(s) in the Paging Group)

FAData Path FnPA(s) Relay PC(s) Anchor PC/LR

Down Link Data

Initiate_Paging_Req(MSID, paging ) indInitiate_Paging_Rsp(MSID, service )ind

BS BroadcastPaging Message

MS HA

applicable PA(s) in PG)Paging_Announce (to

12

Figure 7-112 - Paging Generated for MS by Incoming Packets for MS in Idle Mode 13

Paging flow: 14

(1) HA sends downlink data to MS over MIP4 tunnel to Data Path function associated with FA/AR. In the event 15 that there is no FA/AR (e.g., MIP6), the incoming data will be buffered at the anchor DPF (not shown in the 16 figure). 17


Page - 219


(2) The Anchor Data Path Function recognizes that MS is in Idle mode. Receiving downlink data triggers sending 1 Initiate_Paging_Req to Anchor PC to initiate Paging. (Anchor Data Path function keeps track of MS’s Anchor 2 PC). Initiate_Paging_Req contains: MSID, indication that MS is a paging candidate. 3

(3) Anchor PC sends Initiate_Paging_Rsp to Data Path function. This message may be utilized to indicate that the 4 MS is authorized for service. For such a case, Initiate_Paging_Rsp contains: MSID, and service authorization 5 indicator. 6

(4) Anchor PC retrieves the MS paging info (comprising PGID, paging cycle, paging offset, a relay PCID, or a set 7 of BSIDs including last reported one) and constructs Paging_Announce message. The Anchor PC may issue one 8 or more Paging_Announce messages ba sed on i ts kn owledge of t opology of t he Paging region. F igure 7 -96 9 depicts two alternative methods (step 4a and 4b, respectively) for generating Paging_Announce messages: 10

a) Anchor PC may be topologically aware of Paging region to be Paged (e.g., PG). For example, it may be 11 aware of BSs in region. In this case, the Anchor PC may issue Paging_Announce messages to one or 12 more BSs and/or relay PCs in this region, or, 13

b) The Anchor P C may be topologically unaware o f t he P aging r egion e xcept that i t i s a ware o f one o r 14 more Relay PCs that can forward the Paging_Announce message appropriately to the Paging region. In 15 this case, t he Anchor P C may i ssue Paging_Announce message t o t his r elay P C ( or r elay P Cs) t hat 16 would in turn forward it to the Paging region. 17

Messages 4a) and 4b) can also be used to cancel Paging_Announce. This can happen in the events such as: 18 the MS is successfully paged by one of the BSs or PC wants to stop paging, etc. 19

(5) Relay P Cs r eceiving P aging R equest for t he s pecific P G f orward i t t o t he r elevant B Ss o r o ther r elay P Cs 20 associated with the PGID received in Paging Request. 21

(6) BSs send BS Broadcast Paging Message requesting that MS exit Idle mode. If not receiving response from MS, 22 BS has to resend BS_Broadcast_Paging Message as specified in IEEE 802.16e specification. 23

Other paging scenarios described above would follow steps 4a-6 as in the above figure. 24

Note: The above flow does not illustrate termination of Paging Broadcast by BS. 25


Page - 220


The following depicts an example of the message flow for MS exiting IDLE mode procedure: 1

Net Entry Completion

14

13

12

11

10

9

8

7

6

5

4

3

2

1

BS-Authenticator Interaction

MS PA/BS DataPath FnRNG_Req

(PCID, HMAC/CMAC)

DataPath Fn

IM_Exit_State_Change_Req

PagingRelay FA/AR Data

Path Fn PC/LR Authenticator

Path_Reg_Req

RNG RSP

(HMAC)

Delete MSEntry Req


3a

IM_Exit_State_Change_RspIM_Exit_State_Change_Rsp

Path_Reg_Req

Path_Reg_RspPath_Reg_Rsp

Path_Reg_Ack

Path_Reg_Ack


IM_Exit_State_Change_Rsp

2

Figure 7-113 - MS Exiting Idle Mode 3

Flow description: 4

1) MS initiates exit from IDLE mode procedure (e.g., as a r esult of Paging) and sends RNG_REQ as described in 5 IEEE Std 802.16. Ranging Purpose Indication must be set to one (1) and PC ID TLV must be present, thus 6 indicating that the MS intends to Re-Entry from Idle Mode. 7

2) BS receives RNG_REQ message from MS. Correspondingly, PA sends IM-Exit-State-Change Request to Paging 8 Relay (when PA is not directly connected to Anchor PC, as shown). IM-Exit-State-Change Request contains the 9 following information from the RNG_REQ: MS ID (MAC Address), BSID, PC ID (PCID). If the BS has the 10 Authenticator ID and CMAC/HMAC digest already when the BS receives RNG-REQ message from MS, the 11 BS_Authenticator interaction procedure of verifying RNG-REQ can be started simultaneously. 12

3) Paging Relay receives IM_Exit_State_Change_Req from BS and sends it to Anchor PC. Paging Relay recognizes 13 the PC according to the received PCID field. IM_Exit_State_Change_Req contains the following information: 14 MS ID (MAC Address), BSID. 15

4a) When receiving the IM_Exit_State_Change_Req, the Anchor PC/LR proceeds to request the security context 16 from th e Anchor Authenticator a nd r eceives it in a n IM_Exit_State_Change_Rsp message. I f t he P C an d 17 Authenticator are co-located this step is not required. It also initiates the cancel Paging Procedure at this point. 18

4b) A nchor P C r eceives t he IM_Exit_State_Change_Req, a nd s ends IM_Exit_State_Change_Rsp to t he P aging 19 Relay. IM_Exit_State_Change_Rsp contains th e f ollowing in formation: M SID, I D o f A nchor D PF, 20 Authenticator ID, MS Idle Mode Retain Information, (SFIDs, CIDs, QoS context, etc.). 21


Page - 221


5) Paging R elay forwards t he IM_Exit_State_Change_Rsp to th e B S; T he AK i s fetched f rom th e a ppropriate 1 authenticator in order to verify the RNG-REQ. 2

6) The Data Path function in BS starts data path establishment – it sends Path_Reg_Req to the Data Path Function 3 across R6 . Path_Reg_Req contains t he f ollowing i nformation: M SID, D ata P ath F n ID (e.g., I P A ddress), 4 Service Flow info (SFIDs, QoS context, etc.) It also initiates the cancel Paging Procedure at this point. 5

7) The Data Path Function across R4 continues data path establishment to the anchor Data Path function (which 6 could be collocated with FA/AR as shown in the figure) - sends Path_Reg_Req to anchor Data Path Function. 7 Path_Reg_Req contains the following information: MSID, Service Flow info (SFIDs, QoS context, etc.). 8

8) The anchor Data Path Function confirms data path establishment - sends Data Path Establishment across R4. 9 Path_Reg_Rsp contains: MSID, Service Flow info (SFIDs, Tunnel parameters, QoS context, etc.). 10

9) The Data P ath functions c ross R 6 co nfirms d ata path e stablishment toward S BS - sends Data P ath 11 Establishment Response to the Data Path Function in SBS. Path_Reg_Rsp contains: MSID, Service Flow info 12 (SFIDs, QoS context, etc.). 13

10) BS sends RNG_RSP to the MS formatted according to IEEE 802.16e specification. This RNG_RSP SHOULD 14 deliver information necessary to resume service in accordance with Idle Mode Retain Information. 15

11) The MS completes Network Re-Entry from the Idle Mode as described in IEEE 802.16e specification. 16 12) Upon the MS Network Re-Entry completion the BS sends Path_Reg_Ack to the Data Path function across R6 17

confirming data path establishment completion. Path_Reg_Ack message contains: MSID. 18 13) The D ata P ath function acr oss R4 s ends Path_Reg_Ack to t he a nchor D ata P ath function. Path_Reg_Ack 19

contains: MSID. 20 14) The anchor Data Path function sends a D elete MS entry message to PC/LR in order to delete the idle mode 21

entry associated with the MS in the PC. 22

7.10.3.3 MS Performing Location Update, Secure Location Update 23 MS p erforms Location U pdate pr ocedure w hen i t meets t he LU c onditions a s s pecified i n I EEE 802. 16e 24 specification. The MS shall use one of two processes for Location Update: Secure Location Update or Unsecure 25 Location Update. Un-Secure Location Update p rocess i s performed when MS a nd BS do no t share va lid security 26 context means that BS i s not ab le to receive a v alid AK ( e.g., MS crossed Mobility Domain boundaries o r PMK 27 expired). 28

Un-Secure Location Update results in MS network re-entry and re-authentication. It is performed in the same way as 29 a regular MS network entry process. 30

The Secure Location Update procedure: 31


Page - 222


2

1

3

45

6

7

8

IF SBS does not have security context necessary to validate the LU RNG-REQ message,SBS may use the security defined method to acquire the appropriate security context

LU Req

RNG RSP

RNG-REQIncluding LU flag, PC

ID, and HMAC/CMAC

MS PA Paging relay A_PC/LR Authenticator

9

Context Request

Context Response

LU Confirm1011 Context

Response Ack

LU Rsp

LU Req

LU Rsp

LU Confirm

1

Figure 7-114 - Secure Location Update 2

1) MS initiates Location Update, or the Location Update is forced by network if the conditions described in IEEE 3 Std 802.16e ar e m et an d as a r esult, t he MS s ends R NG_REQ. Ranging P urpose I ndication must b e s et as 4 described in IEEE Std 802.16e indicating that the MS intends to update its location. PC ID (which points to PC 5 acting as MS’s Anchor PC) must also be present. 6

2) PA sends LU_Req to the Paging Relay (as shown in the figure). It contains information like PCID, BSID. 7 3) Paging Relay s ends LU_Req to A nchor P C. I t contains: MSID, B SID and r ecommended p aging p arameters 8

(PGID, Paging cycle, Paging Offset) etc. 9 4) When PC/LR receives a LU_Req message and the security information is not retained in the LR, it will request 10

the security information from the Authenticator. If the PC and the Authenticator are co-located this step is not 11 required. 12

5) If t he LU_Req is accepted by Anchor PC and the Paging operation is s till continuing, at this step 13 Paging_Annouce to ‘Stop Page’ may also be sent to the Paging groups defined for the MS. Anchor PC either 14 accepts t he r ecommended p aging p arameters o r as signs new P GID an d t he p aging parameters an d s ends 15 LU_Rsp message t o Paging r elay. LU_Rsp includes: M SID, B SID, P GID an d p aging p arameters, Anchor 16 Authenticator ID, PCID, etc. 17

6) Paging Relay forwards LU_Rsp to PA. 18 7) BS ( where P A r esides) d etermines whether i t h as a v alid AK f or t he M SID from t he i ndicated Anchor 19

Authenticator. If it does not, the BS sends Context_Req (not shown in the diagram) to the Anchor Authenticator. 20 Context_Rpt (not s hown) p rovides t he AK s equence n umber, as well as t he A K f or t he B S-MS s ecure 21 association (as specified in 7.4.5"Context Transfer Protocol". 22

8) BS ( where P A r esides) uses AK t o ve rify t he i ntegrity of t he RNG-REQ r eceived f rom MS . I f the MS ’s 23 RNG_REQ i s successfully verified, t he B S responds to the MS with RNG_RSP with HMAC/CMAC. I f t he 24 RNG-REQ could not be ve rified ( such a s when t he Anchor Authenticator could no t p rovide an AK), the BS 25 begins the “Un-secure Location Update” sequence by initiating re-authentication. 26

9) In the case where RNG_REQ was verified, PA sends LU_Cnf to Paging Relay (incl. BSID, success indication). 27 It indicates location update from MS has been authenticated and the process is successfully completed. 28

10) Paging Relay forwards LU_Cnf to Anchor PC. Anchor PC receives LU_Cnf and finally updates MS location in 29 the LR. In the event that the Location Update was triggered by paging the MS, the PC/LR initiates the cancel 30 paging procedure (as described above). It may send the Paging Announce message to stop the paging operation 31 within the paging groups. 32

11) If PC relocation has occurred during the LU procedure, the PC will send Context Response Ack message with 33 the LU result to the Authenticator. 34


Page - 223


7.10.3.4 Paging Operation and R3 Mobility Management 1 Migration of foreign agent while the MS is in idle mode (e.g., when idle mode MS moves) shall be considered an 2 implementation o ption. Such F A/AR migration r equires th at MS c ome o ut o f id le mode to c omplete M IP 3 registration procedure. 4

The alternative is to not migrate FA/AR while MS remains in idle mode. For such a scenario, the following points 5 are noteworthy: 6

1) For the registration lifetime for L3 connectivity (e.g., MIP registration lifetime or DHCP lease time), the idle 7 mode MS shall retain its IP address without IP address renegotiation. Registration lifetime will be set to max by 8 the MS when Idle mode is entered. 9

2) While MS moves acr oss P G b oundaries, i t p erforms LU as p er p rocedures ab ove, without r esulting i n a ny 10 FA/AR migration. During this t ime, R3 shall be maintained between Home Agent and the FA/AR. I f Anchor 11 DPF and FA/AR are not collocated, the bearer tunnel between the FA/AR and Anchor DPF is also maintained. 12

3) Upon packet arrival at HA destined for MS, and their delivery over R3 to Data Path function associated with 13 FA/AR, packets shall be buffered in ASN until MS paging procedures are completed. 14

4) The Anchor P C sends Paging_Announce over R 4 using either t opologically aware or topologically unaware 15 procedures. Paging Relays receiving Paging_Announce from PC forward it over R6 interface to all the BSs (or 16 Paging Relay(s)) associated with the PGID in the Paging Request.) via single step or multi-step procedures (see 17 stage 3 for details). 18

5) MS performs a full network entry. 19 6) MS may re-register with its old Home IP address. Tunnel establishment (over R6 and R4) is performed between 20

Data P ath f unctions in S BS, i ntermediate D ata P ath F unctions, an d t he D ata P ath f unction as sociated with 21 FA/AR in a way similar to HO process. 22

7) Packets are transferred from Data Path associated with FA to other Data Path Functions in the path over R4. 23 8) R3 tr affic a nchor p oint ( i.e., Data P ath f unction associated with F A/AR) an d F A/AR may migrate from t he 24

current Anchor point to another Anchor point or may optionally stay as they are. 25 9) When MS goes out of Idle Mode, the PC/ LR entry corresponding to this MS is deleted. 26 10) When MS goes into Idle Mode, serving FA/AR could migrate to the same ASN as the anchor authenticator or as 27

the anchor PC. This is left as an implementation option, as Idle but s tationary MS will not benefit from such 28 migration. 29

11) As the MS has no way to determine a-priori whether it shares a valid security context with the BS, the MS will 30 always i nclude a HMAC/CMAC t uple i n t he RNG-REQ. T he B S a nd t he a nchor a uthenticator will e ither 31 validate the HMAC/CMAC or reject the LU_Req. 32


Page - 224


7.10.3.5 MS entering IDLE mode 1

MS PC ( local/relay)PA DPF DPF Anchor DP

1 ) DREG_REQ

Anchor PC & LR

Anchor Authenticator

2 ) IM_Entry_State_ Change_Req


8 ) IM_Entry_ State_ Change_Rsp9 ) IM_Entry_State_ Change_Rsp

5 ) IM_Entry_State_ Change_Rsp

7 ) IM_Entry_State_ Change_Rsp

6 ) IM_ Entry_State_ Change_Req


10) DREG_CMD11) Path_ Dereg_Req

12) Path_ Dereg_Req

13) Path_ Dereg_Rsp14) Path_ Dereg_Rsp

15) Path_ Dereg_Ack

16) Path_ Dereg_Ack

2 3

Figure 7-115 - MS Entering Idle Mode 4

Dashed arrows are internal to network elements and out of scope. 5

MS enters Idle mode when there is no data to exchange between the MS and the network. MS Idle mode entry could 6 be initiated by either the MS or the BS. 7

1) If M S d ecides t o i nitiate en try i nto I dle Mo de, t hen i t s ends D REG_REQ formatted as d escribed i n I EEE 8 802.16e. The De-Registration Request Code is set to 0x01 indicating that the MS intends entering Idle Mode. 9

2) Regardless of who (MS or BS) initiated the entry into idle mode, the PA in the serving BS sends 10 IM_Entry_State_Change_Req message to its local Paging Controller (who oversees paging at this base station). 11 The IM_Entry_State_Change_Req contains the following information: MSID, BSID, PG_ID, Idle Mode Retain 12 Information, etc. 13

3) Upon receipt of IM_Entry_State_Change_Req from the PA, the local PC assigns an Anchor PC for this mobile, 14 and p uts t his i nformation as a r ecommendation i nto t he message. T he ch osen an chor P C co uld b e t he l ocal 15 Paging Controller itself or a different PC based on implementation considerations such as network policy, MS 16 profile or Relay PC loading conditions. Further, the local PC sends the IM_Entry_State_Change_Req message 17 to the recommended Anchor PC, the IM_Entry_State_Change_Req message contains the following information: 18 Recommended P C_ID, PG_ID, P aging_CYCLE, P aging_OFFSET, s ome M S c ontexts (including A nchor 19 Authenticator ID, Anchor DPF ID etc. 20

4-5 The Anchor PC contacts the Anchor Authenticator to verify that the MS is allowed to enter Idle mode, and may 21 transfer some security context to Anchor Authenticator to retain, such as PKM contexts. Anchor Authenticator 22 records the Anchor PC ID into MS context and reply IM_Entry_State_Change_Rsp to Anchor PC including Idle 23 mode authorization indication. 24

6-7) These steps represent the handshake between the Anchor PC and Anchor DPF of the MS entering Idle mode. 25 Anchor P C/LR s ends IM_Entry_State_Change_Req message t o t he Anchor D PF/FA/AR t o i ndicate t he M S 26 entering Idle Mode. The Anchor DPF updates the information of this MS including the Anchor PC ID of this 27 MS, and then the Anchor DPF responds back with IM_Entry_State_Change_Rsp to Anchor PC/LR. 28


Page - 225


8) If confirmed, Anchor PC either accepts the recommended paging parameters and PGID or newly assigns these 1 parameters and updates Location Register with current information including the DPF ID, and sends 2 IM_Entry_State_Change_Rsp back to the Local PC. The IM_Entry_State_Change_Rsp contains: MSID, actual 3 paging p arameters ( selected PGID, P aging CYCLE, P aging OFFSET), P CID (The I D o f t he G W Acting a s 4 Anchored PC formatted as specified in IEEE 802.16e to be delivered to the MS with DREG_CMD as “PC ID”) 5 and IDLE mode authorization indication. 6

9) The Local PC forwards the IM_Entry_State_Change_Rsp message to PA. 7 10) The PA sends DREG_CMD to the MS either in response to its DREG_REQ or as an unsolicited response (BS 8

initiated entry into idle mode), as specified in IEEE Std 802.16e containing “PC ID” field in the DREG_CMD 9 which points t o t he assigned Anchor PC for t he M S, t he a ssigned Paging CYCLE, and the assigned Paging 10 OFFSET. 11

11-14) After receiving D REG_REQ message from MS a nd t he ex piration o f the M anagement Resource Holding 12 Timer, the DPF associated with PA located in BS initiates the related R6, R4 data path release procedure. 13

Note: The procedure illustrated in Figure 7-115 and described here is the general procedure of accomplishing entry 14 into idle mode. The procedure can be optimized by changing t he s equence a nd f low of messages. The 15 implementation would still be compliant to the specification as long as the messages and functional behaviors are 16 not changed. Implementation details and optimizations are out of Stage 2 document scope, therefore a general case 17 is described in this document. 18

7.11 Data Path 19

Section 7.7.2.2.2 introduces Type 1 Data Paths for carrying ei ther IP or Ethernet packets between peers within an 20 ASN o r b etween ASNs. U ser p ayload p ackets ar e t ransferred o ver T ype 1 D ata P aths b etween ASNs ( R4) o r 21 between the BS and the ASN-GW of an ASN exposing an interoperable R6 reference point. The functions to set up 22 and manage such data paths are described in Section 7.7.2.2.2.2. 23

This section provides additional information about the encapsulation and transport of user payload packets within 24 and between ASNs, between ASN and CSN and between CSNs. Detailed packet formats and tag values are given in 25 Stage 3. For an IP based transport architecture an IP-in-IP type of tunnel protocol has to be applied. GRE is taken as 26 an example in this section to show the required functions of the tunnel protocol. 27

7.11.1 Transport of user payload over R1 28 For t ransport of u ser pa yload pa ckets ov er R 1, t he [ 1] s pecification a mended b y [ 2] supports v arious t ypes of 29 convergence s ub-layers to address different types o f s ervice deployment scenarios. The packet convergence s ub- 30 layer ( Packet C S) p rovides d ifferent p ayload s pecific p arts for E thernet as well as f or I P defining s pecific 31 classification and e ncapsulation f unctionalities. The terms IP-CS, IPv4-CS, IPv4oETH-CS and ETH-CS are u sed 32 within this chapter to refer to variants of the Packet CS supporting the transport of specific user payload type packets 33 over the R1 interface. For example, IP-CS refers to a Packet CS with the IP specific p art supporting tr ansport o f 34 plain IP packets as IEEE Std 802.16 user payload; IPv4-CS is used to emphasize the IP version of the IP packets 35 when appropriate. ETH-CS denotes the Packet CS with the IEEE 802.3/Ethernet-specific part for the t ransport o f 36 Ethernet frames as IEEE Std 802.16 user payload over the R1 interface, and IPv4oETH-CS is used for a Packet CS 37 with the IEEE Std 802.3/Ethernet-specific part specialized for the transport of Ethernet-encapsulated IPv4 packets as 38 IEEE Std 802.16 user payload over the R1 interface. 39

If i mplemented, s everal d ifferent c onvergence s ub-layers SHALL c oexist within t he s ame ASN, e .g. I Pv4-CS 40 SHALL coexist i n the same ASN with IPv4oETH-CS, if both are s upported. Handover o f MS f rom an Ethernet 41 based CS t o a p lain I P b ased C S within t he s ame ASN o r when moving from one ASN t o a nother ASN is not 42 supported. 43

44


Page - 226


7.11.2 Transport Architecture for IP services 1

7.11.2.1 IP Services 2

7.11.2.1.1 IP Connectivity for a Single Host MS 3 A single IP address is assigned to the MS deploying different CIDs for up and downlink. 4 Multiple CID assignments are possible to provide multiple service flows under the same IP address. 5

7.11.2.1.2 IP Connectivity for Multiple Hosts behind the MS 6 for further study. 7

7.11.2.2 IP-CS Transport Architecture 8 The IP convergence sub-layers are defined in [1] and [2] in Section 5.2.6. When one of the IP CS is employed, plain 9 IP datagrams are carried in the payload of 802.16 PDUs. Classifiers for IP CS connections can make use of fields in 10 the I P h eader a s well a s s ource a nd de stination por t num bers o f t ransport pr otocol f ields. T he P acket H eader 11 Suppression (PHS) can replace the header and also the higher layers with a one-byte PHS-Index, and can be used as 12 well as Robust Header Compression (RoHC) as optional methods to reduce the header overhead going over the air. 13

Figure 7-116 shows the generic protocol layering for the control plane as well as the data path applying IP-CS on 14 R1, R6 (when exposed), R3 and R5. GRE is used as an example of an IP-in-IP tunnel protocol. 15

BS ASN-GW

ASN

CSN CSNMS

R1R6

R3 R5

16 CNTLMACPHY

MACPHY

IPIP CS

IPLINK

IPGRE

PHY

PHY

ASN CRTLIP

LINK

Control

Data Path

16 CNTLMACPHY

PHY

ASN CRTLIP

LINKPHY

CSN CRTLIP

LINKPHY

CSN CRTLIP

LINK

MACPHY

IPIP CS

IPLINK

IPGRE

PHY

LINKPHY

IPXXX

LINKPHY

IPXXX LINK

PHY

IPLINKPHY

IP

16

Figure 7-116 - Protocol Layer Architecture for IP service over IP-CS 17

‘XXX’ in the protocol stacks on R3 denote either the data path tunneling protocol used for PMIP or CMIP over R3, 18 or any IP transport protocol in the case of Simple IP. 19

With IP-CS the MS SHALL encapsulate IP datagrams from the IP host layer into 802.16 MAC frames for upstream 20 over the R1 reference point. The BS (on ASN side) SHALL encapsulate IP datagrams received from the ASN-GW 21 via R6 into 802.16-MAC frames for downstream over R1. All IP datagrams are assigned to CIDs and transferred 22 over R1 according to the applied classifiers. 23

7.11.2.3 IPoETH-CS Transport Architecture 24 The IP over Ethernet convergence sub-layers are defined in [1] and [2] in Section 5.2.4. When one of the IP over 25 Ethernet CSs is deployed, IEEE802.3 framed IP packets are encapsulated in the payload of 802.16 PDUs. Classifiers 26 for IP over Ethernet CS connections can make use of fields in the 802.3 header as well as higher layer protocol 27


Page - 227


fields. The optional Packet Header Suppression (PHS) can serve to replace the entire 802.3 header and eventually 1 even higher layer header fields with a one-byte PHS-Index. RoHC can be supported as well as option to compress 2 the RTP/UDP/IP header portion of VoIP packets. 3

Figure 7-117 shows the generic protocol layering for the control plane as well as the data path applying IPoETH-CS 4 on R1, R6 (when exposed), R3 and R5. GRE is provided as example of an IP-in-IP tunnel protocol. 5

BS ASN-GW

ASN

CSN CSNMS

R1

R6

R3 R5

MACPHY

IPETH

ETH CS

Control

Data Path

MACPHY

IPETH

ETH CSIP

PHY

IPETHGRE

LINKIP

PHY

IPETHGRE

LINKPHY

IPXXXLINK

PHY

IPXXXLINK PHY

IPLINK

PHY

IPLINK

PHY

CSN CRTLIP

LINKPHY

CSN CRTLIP

LINKPHY

ASN CRTLIP

LINKPHY

ASN CRTLIP

LINKPHY

16 CNTLMAC

PHY

16 CNTLMAC

6

Figure 7-117 - Protocol Layer Architecture for IP services over IPoETH-CS 7

‘XXX’ in the protocol stacks on R3 denote either the data path tunneling protocol used for PMIP or CMIP over R3, 8 or any IP transport protocol in the case of Simple IP 9

IEEE Std 802.16 MAC frames are p rotected by a M AC layer FCS. The FCS t railer o f E thernet packets does not 10 provide a higher level o f p rotection and will suppressed for the tr ansmission over the a ir, a s defined by [2]. This 11 reduces the packet overhead by 4 bytes. The Ethernet FCS is re-generated at the receiving side out of the transmitted 12 data and appended to the packet. 13

To reserve resources over the R1 reference point, Ethernet broadcast packets SHOULD be filtered. The filter MAY 14 be implemented at the MS or the ASN (using classifiers with the "Drop action" or with a filter above the MAC 15 layer) so as to restrict inappropriate traffic from the radiolink; or the ASN MAY respond to ARP requests rather than 16 propagating them. Both kind of filtering SHALL have the ability of being enabled or disabled. Details of operation 17 are given in Stage 3. 18

7.11.3 Transport Architecture for Ethernet Services 19

7.11.3.1 Ethernet Services 20 Ethernet Services and VLAN support provide transparent layer 2 connectivity between a MSs and a port at the 21 Ethernet bridge in the CSN, where the MS is anchored. The bridge port SHALL NOT change while the MS is 22 moving inside the Mobile WiMAX® network. Anchoring the layer 2 connectivity of moving terminals at a fixed 23 location inside the CSN allows for the deployment of usual provider bridges for realizing the Ethernet services in 24 Mobile WiMAX. 25

Ethernet header fields like source MAC address, destination MAC address, ETHERTYPE but also VLAN-ID and 26 priority field when available, and eventually in addition IP header and protocol fields MAY be used for 27 classification to assign Ethernet frames to particular service flows over the air. 28


Page - 228


Forwarding of Ethernet frames between ASN and CSN, as well as between V-CSN and H-CSN in the roaming case 1 SHALL be performed according to the MSID of the terminal instead of destination MAC addresses in the payload. 2 The details of the encapsulation and flow marking to realize appropriate forwarding depends on the data path 3 protocol deployed on the particular link. 4

For segregation of traffic in the network, the assignment of S-VIDs and service provider tags to frames with or 5 without C-VIDs SHALL be supported according to [82]. It SHALL be possible to append S-VIDs to Ethernet 6 frames according to service flows, MSIDs or customer provisioned C-VIDs. 7

7.11.3.2 ETH-CS Transport Architecture 8 The Ethernet convergence sub-layer is defined in [1] and [2] in Section 5.2.4. When the Ethernet CS is deployed, 9 IEEE 802.3 f rames are encapsulated in the payload o f 802.16 PDUs. Classifiers for E thernet CS co nnections can 10 make use of fields in the 802.3 header as well as in the VLAN protocol fields and in addition of fields in the IP layer 11 when present. Packet header suppression (PHS) allows to replace the entire Ethernet/VLAN header and eventually 12 higher layer header fields with a one-byte PHS-Index for the transmission over the air. 13

ROHC compression MAY be deployed on IP header information carried in Ethernet frames before suppression of 14 the Ethernet header fields by PHS, if IP payload is carried. 15

Figure 7-118 shows t he generic p rotocol l ayering f or t he control p lane as well a s t he data p ath for e nd-to-end 16 Ethernet services applying ETH-CS on R1. GRE is used as example of an IP tunnel protocol on R6 (when exposed) 17 and R3 f or tunneling E thernet f rames o ver a n IP t ransport i nfrastructure. F or S imple E thernet, t he R 3 tunneling 18 mechanism is not standardized and MAY be based on any appropriate layer 2 or layer 3 protocol. The R5 data path 19 MAY be based on Carrier Ethernet connectivity and MAY deploy stacked VLAN-IDs according to [84] for traffic 20 separation independent of the MAC addresses of the payload. 21

BS ASN-GW

ASN

CSN CSNMS

R1

R6

R3 R5

MACPHY

ETHETH CS

Control

Data Path

MACPHY

ETHETH CS

IP

PHY

ETHGRE

LINKIP

PHY

ETHGRE

LINK PHY

ETHXXXLINK

PHY

ETHXXXLINK PHY

ETHLINK

PHY

ETHLINK

PHY

CSN CRTLIP

LINKPHY

CSN CRTLIP

LINKPHY

ASN CRTLIP

LINKPHY

ASN CRTLIP

LINKPHY

16 CNTLMAC

PHY

16 CNTLMAC

22

Figure 7-118 - Protocol Layer Architecture for ETH-CS 23

‘XXX’ in the protocol stacks on R3 denote either the GRE tunneling protocol used for MIP based Ethernet transport 24 over R3, or any Ethernet transport protocol in the case of Simple Ethernet. 25

A bridge is deployed in the CSN for forwarding packets between the ASN and the R5 interface. The efficiency of 26 carrying Ethernet frames over the WiMAX® radio interface SHOULD be enhanced by applying the methods defined 27 in [85] to the operation of the bridge. 28


Page - 229


7.11.3.3 ETH CS Packet Transmission Format over R1 1 IEEE 802.16 MAC frames are protected by a MAC layer FCS. The FCS trailer of Ethernet packets does not provide 2 a higher level of protection and will be suppressed for the transmission over the air, as defined by [2] which reduces 3 the per packet o verhead b y 4 b ytes. T he E thernet FCS SHALL b e re-generated o ut o f t he t ransmitted d ata an d 4 appended to the packet when forwarding the packet over an IEEE 802.3 PHY. 5

FCS

Data

0x8100 Tag Control Information Data FCS

Transmission of IEEE 802.1Q over R1

IEEE 802.1Q frame format

Transmission of Ethernet over R1

Ethernet frame format

Length/TypeDA SA

DA SA Length/Type

0x8100 Tag Control Information DataDA SA Length/Type

DataLength/TypeDA SA

6

Figure 7-119 - FCS Suppression Over R1 7

7.11.4 Tunneling within the ASN 8 If GRE is used as the tunneling mechanism over R6 between the ASN-GW and the BS and over R4 between ASN-9 GW and ASN-GW, then the Tunneling Info Extension SHOULD be set to GRE. The value for the GRE Key is 10 negotiated b etween t he ASN-GW and t he B S or be tween A SN-GW a nd ASN-GW. T he G RE P ayload P rotocol 11 Types are assigned according to [3] for IP and Transparent Ethernet Bridging. 12

The encapsulation format for GRE appears in Figure 7-120. 13


Page - 230


IP Ver IP HLEN DSCP IP Datagram Total Length

IP Identification Flags IP Fragment Offset

IP Header Checksum

Source IP Address (e.g., BS)

Destination IP Address (e.g., ASN-GW EP)

GRE Payload Protocol Type (might be eitherIP or Ethernet)VerReserved0

Start of Encapsulated Payload

GRE Key

Sequence Number

0 11

IP Time to Live IP Protocol

1

Figure 7-120 - GRE Encapsulation 2

• DSCP in the Encapsulation IP Header specifies the QoS Class. Note that it MAY differ from the DSCP or 3 the priority bits in the Encapsulated Payload. 4

• Source and Destination IP Addresses specify the tunnel end points. 5

• The meaning of the GRE Key value is defined by the node that allocates the Key value. 6

• The Sequence Number MAY be used for synchronization of Data Delivery during HO. 7

Figure 7-121 shows an example of the Data Path with GRE Encapsulation within the ASN for IP services. 8

IP (or MIP)

802.16MAC

802.16PHY

802.16MAC

802.16PHY

GRE

IP

GRE

IP

GRE

IP

GRE

IP

MIP

IP

MIP

IP

Data Path Func.BS

Data Path Func.ASN GW (Serv.)

Data Path Func.ASN GW (Anc.) HA

R3R4R6R1

MS

IP Routing IP Routing

9

Figure 7-121 - GRE Encapsulation for IP CS 10

The same Data Path can be used either for Simple IP, Proxy MIP or for Client MIP in the case of IP services as well 11 as for Simple Ethernet and MIP based Ethernet in the case of Ethernet services. 12


Page - 231


The BS maps the IEEE Std 802.16 Connections (CID) on the R6 GRE Tunnels for both downstream and upstream 1 traffic. There is 1 to 1 correspondence between the IEEE Std 802.16 Connections and the GRE Keys according to 2 per Service F low granularity on R6/R4. T he BS does not need to implement any IP routing or E thernet b ridging 3 functionality. This mechanism is applied either for unicast or for multicast traffic. 4

The ASN-GW terminates the R6 Tunnels from BS. Various encapsulation techniques (e.g., GRE, MPLS, etc.) might 5 be used for R6 Tunnels and the granularity of the tunnel IDs might also vary (e.g., the Tunnel IDs might be assigned 6 per Connection, per MS, per IP Realm, etc.). The R6 Data Path Function protocol supports encapsulation type and 7 Tunnel ID granularity negotiations. 8

Anchored ASN-GW (Data Path Function) SHALL classify the downstream traffic resulting in per SF 9 granularity on R4 and R6. 10

7.11.5 Tunneling over R3 11 IPinIP as well as GRE may be used for transferring the payload of IP services over R3. 12

For both MIP-based and Simple Ethernet services it is necessary to deploy a t unneling protocol for R3. For MIP-13 base E thernet services, the tunneling protocol must have the cap ability t o encapsulate Ethernet f rames within I P 14 packets like GRE. 15

For both, Mobile IP services as well as MIP-based Ethernet services, the Mobile IP protocol is used for the dynamic 16 establishment and the maintenance of the transport over R3. 17

Simple IP and Simple Ethernet services are not required to perform dynamic establishment of transport over R3. 18

7.11.6 Transport of payload over R5 19 The transport protocol for the statically configured R5 data path is not standardized. 20

7.12 VoIP Services 21

This section does not apply for Ethernet services. 22

While existing mechanisms specified in the QoS framework and accounting and charging framework could be used 23 by th e C SN o perator to s upport V oIP, f ulfillment o f a ll quantitative r equirements, r egulatory r equirements a nd 24 requirements mentioned in Section 7.12 for VoIP are outside the scope of this release. 25


Page - 232


7.12.1 Emergency Service 1 Emergency Service is considered as a n on-subscription based service, provided by the network operator (NSP) or 2 third party IP service providers (ASP). This service does not require explicit authentication and authorization of the 3 Caller. Decision on the access authentication for us ing e mergency service a nd analysis of the security threats a re 4 FFS. 5

Figure 7-122 depicts the high-level view of the emergency service architecture. 6

ExternalNetwork

EmergencyCentre(PASP)IP/SS7

IP/SS7

MediaController

SignalingController

RoutingDirectory

CSN

ASNSS/MSSR1

R3

7

Figure 7-122 - High-Level View of Emergency Service Architecture 8

There are four basic steps involved for supporting emergency service. They are as follows: 9

a) Detection of emergency r equest: Detection of the emergency request MAY be done by the MS or by the 10 network entities within CSN based on certain criteria outside the scope of this release. 11

b) Location i nformation: Caller lo cation p lays a c entral r ole in r outing e mergency c alls. T he lo cation 12 information M AY b e co mmunicated f rom M S, B S, A SN en tities, o r b y s ome o ther m eans. T he ex act 13 procedure on communicating location i nformation as required b y e mergency s ervices r egulatory 14 requirements is outside of the scope of this release. 15

c) Finding the location of nearest P SAP (Public Safety Answering P oint): For practical reasons, each PSAP 16 generally handles only calls for certain geographic area. Also, for time sensitive request like emergency 17 service, it is better to handle request locally. Upon contacting PSAP, it forwards emergency calls to the 18 emergency control center for the purpose of dispatching police, fire and rescue services. The address of the 19 PSAP i s ba sed on t he C aller’s l ocation i nformation. T he s upport i s pr ovided by t he C SN t hrough a 20 functional e ntity labeled as “Routing D irectory.” T his step i s a ssumed t o be supported b y CSN i n this 21 release. 22

d) Routing call to PSAP: Once the location of the Caller and the address of PSAP are identified, the request is 23 routed to the PSAP. This step is also assumed to be supported by CSN in this release. 24

Prioritization of the access and network resources i s typically required in order to support emergency service in a 25 reliable manner. The selection of an appropriate QoS for prioritization required by emergency service is based on 26 the Q oS framework di scussed i n t his doc ument. W hile t he C SN ope rator c ould u se an e xisting Q oS s ignaling 27 method specified in the framework, explicit prioritization support for emergency service support is outside the scope 28 of this release. 29

7.13 Simple IP Management 30

This section describes the high level requirements and procedures for Simple IPv4 and Simple IPv6 services. FA, 31 HA a nd PMIP client functional e ntities are not required in the S imple I P o nly n etwork. C SN anchored mobility 32 service i s n ot provided t o t he MS . During t he acces s authentication p rocedure, the ASN, VCSN and HCSN will 33 participate in the network service capabilities discovery and negotiation. Depending on these networks capabilities, 34 Simple IPv4 or Simple IPv6 services may be setup after successful access authentication. 35


Page - 233


R3 mobility support is out of scope for Simple IP networks When the MS performs network re-entry, the network 1 will require the MS to re-discover the IP address, which could be different from the previous IP address. To provide 2 better session continuity, the ASN may perform R4 handover (refer to section 4.9 in Stage 3) and establish R4 data 3 path between Anchor and Target (new Serving ASN). MS is not required to be aware of the type of service (Simple 4 IP or PMIP) being provided. 5

Simple IP service has no restrictions on the ASN-anchored mobility management. The network MAY still provide 6 the MS with mobility at the 802.16 layer. 7

7.13.1 Simple IPv4 Functional Requirements 8 • The network SHALL support Simple Ipv4 MS using DHCP protocol as per RFC2131 and RFC2132. 9

7.13.1.1 Simple IPv4 Session Setup 10 The MS obtains an IP address via DHCP. The scope of this IP address belongs to CSN. A call flow for Simple IP 11 setup is illustrated in sectionError ! Reference source not found.. 12

7.13.1.2 Simple IPv4 Mobility Management 13 Mobility Management for Simple IPv4 is restricted to ASN anchored Mobility only. CSN anchored mobility is out 14 of scope for Simple IP. If ASN anchored mobility is not provided or MS has been moved out of its current mobility 15 domain, the MS should obtain a new IP address during network re-entry. Note that in the case of simple IP service 16 the anchor DPF function cannot be moved and remains located in the AR where the MS initially at tached for the 17 duration of the MS IP session with the network. Some deployments may move the anchor DPF by terminating the 18 current MS IP session through full network entry and establishing a new IP session anchored in a d ifferent ASN, 19 with the consequence that the IP session continuity is not provided. 20

In a roaming scenario the simple IPv4 service can be provided either by the visited CSN or by the home CSN. The 21 decision which CSN provides simple IPv4 service is defined by the network policy as agreed between the roaming 22 partners. In case that the simple IPv4 service is provided by the home CSN, the router in the visited CSN will need 23 to deliver the MS data plane to the home CSN regardless of the actual destination address in the IP header. 24

This requires the preconfigured data path in place between the home and the visited CSN. The exact mechanisms 25 how data paths between the visited and home CSNs are established are out of the scope of this specification. 26

7.13.1.3 Simple IPv4 Session Renewal 27 Simple I Pv4 se ssion r enewal p rocedure i s a s p er RF C2131, w ith D HCPREQUEST a nd D HCPACK message 28 exchange. 29

7.13.1.4 Simple IPv4 Session Termination 30 Simple I Pv4 s ession r elease i s t riggered b y D HCPRELEASE from t he MS o r a MS t riggered ne twork e xit 31 procedure. 32

The network can also terminate a s imple IPv4 session. The network exit procedure may be initiated in the case of 33 network initiated simple IP session termination or the ISF deleted. 34

7.13.1.5 Simple IPv4 Security 35 There is no additional security requirement for Simple IP. 36

7.13.2 Simple IPv6 Management 37 Simple IPv6 service requires that the MS is provided with IPv6 connectivity. Simple IPv6 service does not provide 38 any support f or mobility management a t t he I P la yer. T he f ollowing f igure il lustrates th e p rotocol s tack f or th e 39 simple IPv6 service: 40


Page - 234


802.16 MAC

802.16 PHY

IPv6

802.16 MAC

802.16 PHY

DP Fn

L1

DP Fn

L1

L2

L1

L2

L1

L2

L1

IPv6 IPv6-over-xxx IPv6IPv6-over-xxx

ASN CSN

BSMS AR CR 1

Figure 7-123 - Simple IPv6 data plane protocol stack 2

Simple IPv6 service and the address assigned to the MS are provided by the CSN. Scope of the IP address assigned 3 to the MS is at the CSN providing the simple IP service. This requires that the ASN transports all uplink IP packets 4 to the CSN regardless of the destination address in the IP header of the packet. The exact mechanism and technology 5 how data paths between the ASN and CSN are set up are out of the scope of this specification. In a roaming scenario 6 the simple IP service can be provided either by the visited CSN or by the home CSN. The decision which CSN 7 provides simple IP service is defined by the network policy as agreed between the roaming partners. In case that the 8 simple IP service is provided by the home CSN, the router in the visited CSN will need to deliver the MS data plane 9 to the home CSN regardless of the actual destination address in the IP header. This requires the preconfigured data 10 path in place between the home and the visited CSN. The exact mechanisms how data paths between the visited and 11 home CSNs are established are out of the scope of this specification. 12

7.13.2.1 Connection Setup for Simple IPv6 Service 13 Connection setup for the simple IPv6 service is illustrated in the figure below. 14

MS CRH-AAAASN

(4) DAD(LLA)

(6) RA(prefix)

(5) RS

(7) configuration of global address

(1) preconfigured data path

(8) address verification

(2) Access authentication

(3) ISF established

15

Figure 7-124 - Connection setup for simple IPv6 service 16

1. Step 1 shows a p reconfigured static Data path between the ASN and CSN. It is used to carry simple 17 IPv6 traffic from the ASN to the CSN which is providing IPv6 service. This step is not part of the MS 18


Page - 235


attachment procedure, but is shown here to emphasize that there MUST be a data path between the 1 ASN and the CSN. The entity in the CSN that terminates the data path is termed core router (CR). 2

2. In step 2 the MS is authenticated for network access. The AAA server shall provide explicit indication 3 which mobility mode i s a uthorized f or t he M S: simple I Pv6, a nd/or C MIP6. O ptionally t he AAA 4 server may provide a p refix that SHALL be used to configure the MS address. This prefix MAY be 5 provided either by home AAA or visited AAA, as per network policy. 6

3. When the establishment of IPv6 CS ISF is completed, the authenticator triggers the collocated AR to 7 start the IPv6 configuration process. 8

4. Triggered b y t he es tablishment o f t he I Pv6 I SF, t he M S co nfigures a l ink l ocal address an d s tart a 9 duplicate address detection process for it. 10

5. Simultaneously with step 4 the MS MAY send a Router Solicitation message to learn available routers 11 on the link. 12

6. Triggered b y t he s tep 3 , t he A R s ends a Router Advertisement message to t he M S. T he R outer 13 Advertisement message may allow for address autoconfiguration in which case it SHALL contain a 14 unique p refix al located t o t his M S. I f t he network p olicy d oes not al low for s tateless ad dress 15 autoconfiguration, the Router Advertisement message SHALL have the ‘M’ bit set instructing the MS 16 to use DHCPv6 for address configuration. 17

7. In this step the MS configures a globally routable IPv6 address, either by using stateless or stateful 18 address configuration mechanisms as instructed in previous step. When using stateful mechanisms, the 19 ASN SHALL provide either the DHCP proxy function or the DHCP relay function. 20 The prefix provided to the MS for address configuration SHALL be unique per MS, as per the Rel 1.0 21 IPv6 link model. If the prefix was not provided to the ASN in a dynamic manner by the AAA in step 2, 22 the ASN SHALL be preconfigured with a pool of IPv6 prefixes that topologically belong to a CSN 23 with which the ASN has a NAP sharing agreement. In this case ASN SHALL use one of the prefixes 24 from the pool for MS address configuration. 25

8. The MS verifies the uniqueness of the address configured in previous step as per RFC 4861. 26

After the MS has completed the above steps, i t has configured its IPv6 stack and is able to use IPv6 service. The 27 ASN SHALL deliver uplink packets from the MS to the CSN providing the IPv6 service to the MS. In case ASN is 28 connected to several CSNs, the ASN SHALL use visited realm of the decorated NAI provided by the MS in step 2 29 as a clue to which CSN it shall deliver the uplink traffic. The same clue is also used to select the right prefix pool in 30 case where AAA doesn’t provide the prefix for MS in a dynamic manner. 31

Any packets received by the ASN in the downlink direction via a preconfigured Data path are decapsulated and then 32 delivered to the MS. The MS is identified using the destination prefix (upper 64 bits of the destination address in the 33 IPv6 header) from decapsulated packet. 34

7.13.2.2 Session Renewal for Simple IPv6 Service 35 Session renewal in the case of simple IPv6 service is about extending the lifetime of the address that the MS uses. In 36 case that stateless address autoconfiguration was used to configure the global address, t he M S a nd ASN SH ALL 37 support mechanisms defined in RFC 4862 for extending the lifetime of autoconfigured address. If the global address 38 was initially configured using DHCPv6, the MS and ASN SHALL support procedures for lease ex tension as per 39 RFC 3315. 40

7.13.2.3 Mobility Management for Simple IPv6 Service 41 Mobility Management for Simple IPv6 is restricted to ASN anchored Mobility only. CSN anchored mobility is out 42 of scope for Simple IP. If ASN anchored mobility is not provided or MS has been moved out of its current mobility 43 domain, the MS should obtain a new IP address during network re-entry. Note that in the case of simple IPv6 service 44 the anchor DPF function cannot be moved and remains located in the AR where the MS initially at tached for the 45 duration of the MS IP session with the network. Some deployments may move the anchor DPF by terminating the 46 current MS IP session and establishing a new IP session anchored in a different ASN, with the consequence that the 47 IP session continuity is not provided in such scenario in the current release of the specification. 48


Page - 236


7.13.2.4 Session Termination for Simple IPv6 Service 1 This section describes how the MS may terminate its current IPv6 session. 2

In case that stateless address autoconfiguration was used to configure the MS global address, the MS has no means 3 to inform the network that it wants to terminate its IPv6 session. In such case the MS MAY de-register with the BS 4 tear down the IPv6 ISF in order to release its simple IPv6 session. In case the network wants to revoke the simple 5 IPv6 session, it SHALL send the Router Advertisement containing the prefix assigned to the MS with the Valid 6 Lifetime field set to 0. This will cause the MS to invalidate its address immediately as per RFC 4861. 7

In case that stateful address autoconfiguration was used to configure a global IPv6 address, the MS SHALL send a 8 DHCPv6 RELEASE message (RFC 3315) to inform the network that it wants to terminate the IPv6 session. If the 9 network initiates the session termination, it SHALL send DHCPv6 RECONFIGURE message to the MS, as per RFC 10 3315. The MS SHALL respond with RENEW message, and in response the network SHALL deny the address to the 11 MS in the REPLY message. 12

13

7.14 Emergency Telecommunications Service (ETS) Support 14

ETS is an optional feature to enable authorized personnel to establish and maintain priority communication using the 15 public ne tworks d uring ne twork c ongestion c ondition. W ithout E TS, t he N ational S ecurity and E mergency 16 Preparedness personnel will suffer from session establishment blocking s imilar to that of the regular public users, 17 and will not be able to carry out mission critical communications during natural and man-made disasters. 18

7.14.1 Potential Congestion Points in the WiMAX® Network 19 ETS support requires a priority solution for E TS s ervices at the points i n the W iMAX® network where ne twork 20 congestion can occur. In the WiMAX network, congestion may occur in the ASN FEs and interfaces (such as R4, 21 R6, and R8), the CSN FEs and interfaces, as well as the over the air interface R1. Interface R5 may be involved in 22 the context of roaming. All these FEs and interfaces are potential congestion points. Supporting ETS prioritization 23 may be needed at these points. 24

7.14.2 ETS subscription types 25

7.14.2.1 ETS user subscription 26 An ETS user subscription enables an ETS user to access and use ETS services independent of the access technology. 27 The E TS u ser s ubscription i n th e c ontext o f t his specification is a n a pplication-level subscription. H ence, it i s 28 independent of a WiMAX subscription that allows access to the WiMAX network. 29

The ETS User is authorized to access the ETS services through the assigned ETS Credentials that are part o f the 30 ETS user subscription (e.g., a Personal Identification Number, or PIN) at the application level. This ensures that the 31 ETS subscriber can also access ETS s ervices independent of the device cap abilities o r the W iMAX s ubscription 32 used. 33

7.14.2.2 ETS enabled WiMAX® subscription 34 To enable ETS support at the time of initial network entry to a WiMAX network, a WiMAX subscription may be 35 ETS enabled. An ETS enabled WiMAX subscription may be linked to the ETS user subscription in determining 36 access to ETS services. 37

Without an E TS en abled W iMAX subscription, E TS u sers with a n E TS u ser s ubscription can not r eceive E TS 38 priority treatment during initial network entry, rather will invoke ETS through application-level authorization. 39

40

Table 7-7 - Subscription types for ETS 41

Provisioned in ETS service invocation (at application level)

Network entry with ETS priority support


Page - 237


Type 1: ETS user subscription

ETS user subscription database

Required Not available

Type 2: ETS enabled WiMAX® subscription WiMAX® AAA server Optional Required

1

7.14.3 Priority Triggers in ETS Support 2 Priority t riggers can be o riginated from any MS, whether o r not the MS enters the network with an ETS enabled 3 WiMAX® subscription. 4

The E TS U ser may b e a uthorized f or E TS s ervices o nly with an ETS u ser s ubscription at t he ap plication l evel. 5 Priority treatment of ETS service requests originated using only ETS user subscription may be different than those 6 originated using an ETS enabled WiMAX subscription. I n particular, an ETS enabled WiMAX subscription may 7 enable p re-invocation o f p riority s ignaling whereas a n ETS u ser s ubscription may require r ecognition o f th e 8 invocation before applying any priority. 9

In th is specification, E TS s upports network i nitiated p riority i ndication f rom th e C SN to the ASN. M S i nitiated 10 priority indication for ETS from the MS to the ASN is for future specification. 11

Upon successful authentication of an MS associated with an ETS user subscription during initial network entry, the 12 serving BS obtains the User Priority Level [103] of the associated ETS user subscription from the QoS Descriptor 13 that ASN receives from the AAA server. 14

Upon ETS invocation from a M S after initial network entry, the Application Function (AF), a P-CSCF in the IMS 15 case o r an ap plication s erver i n t he non-IMS cas e, a uthenticates t he user’s E TS C redential a nd s upplies t he 16 Reservation P riority ( direct o r d erived f rom U ser P riority L evel o f t he invoking Service U ser) a nd Application 17 Identifier [104] a s th e priority i ndication f rom the AF, and then to th e P F/AAA in the n on-PCC ar chitecture (as 18 shown in Figure 7-37 “QoS Functional Elements”). Note that priority indication upon ETS service invocation in the 19 PCC architecture is for future specification. 20

ETS services can be invoked by various user input methods, e .g., typing *272 prefix in an MS associated with an 21 ETS enabled WiMAX subscription, or typing 710-NCS-GETS with the ETS Credential of an ETS user subscription 22 in an M S n ot as sociated with an E TS en abled W iMAX s ubscription, o r t yping a U RL f ollowed b y t he E TS 23 Credential from an MS, or application signaling methods, e.g., Universal Services Interface (USI) from the network 24 or client software in the MS. 25

An example of an ETS Credential is a PIN for accessing an ETS user subscription database. The invocation method 26 of t yping 710-NCS-GETS with the ETS Credential enables an ETS user subscription to use o ther people’s MSs 27 when the MS associated with an ETS enabled WiMAX subscription is out of power, lost, or left at home. 28

Details of end-to-end ETS invocation methods by the users are outside of the scope of the WiMAX specification. 29

7.14.4 Priority Handling for ETS Support 30 The priority handling procedures for ETS support in the WiMAX® network are as follows. 31

1. Upon in itial network e ntry of a n M S a ssociated with a n E TS e nabled W iMAX s ubscription, p riority 32 indications associated with initial and pre-provisioned service flows for the MS are passed from the AAA 33 to th e ASN Gateway, a nd to th e B S. T he B S a pplies priority tr eatment o n r esource a llocation a nd 34 scheduling for the priority service flows. 35

2. Upon ETS invocation from an MS, priority indications associated with service flows related to ETS for the 36 MS ar e p assed f rom t he AF t o t he AAA/PF t o t he ASN G ateway to t he B S. T he B S ap plies p riority 37 treatment on resource allocation and scheduling for the priority service flows. 38

3. Upon handover, priority indications associated with service flows for the MS are retained from the Serving 39 BS to th e T arget B S f or i ntra-ASN ha ndover a nd from t he S erving ASN G ateway t o t he T arget ASN 40 Gateway for inter-ASN handover. The BSs apply priority treatment on resource allocation and scheduling 41 on all priority service flows during handover procedures. 42


Page - 238


4. Upon paging triggered by incoming data to a MS in the idle mode, priority indication associated with the 1 service flow are passed from the ASN Gateway hosting the FA/Data Path Function to the Anchor PC, and 2 then to the PA (in BS). The BS applies priority treatment on resource allocation and scheduling for priority 3 service flows in the b roadcasting paging messages (as described in Stage 3 Section 4 .10.3.5 Step 6). In 4 response to priority paging, when the MS enters the network, the BS should recognize the incoming ETS 5 call p riority a nd g ive t he p riority tr eatment to t he M S f or id le mode e xit a s well a s s ervice flow 6 addition/change for the ETS call to the terminating MS. 7

8

Priority treatment on resource allocation may involve queuing messages related to resource allocation, such as DSA-9 REQ/DSC-REQ r elated t o a llocating t ransport c onnection r esources [ 105] a nd RNG-RSP r elated to a llocating 10 management connection resources [105]. By queuing in the BS these R1 reference point messages associated with 11 the E TS r equests ( in co ntrast t o r ejecting t hose from non-ETS r equests) d uring c ongestion c onditions, t he E TS 12 service has a higher probability of success in establishing connections. 13 14

Priority treatment on resource scheduling/routing may involve the use of priority connection identifier (CIDs) [105] 15 associated with the service flow with ETS priority indication in the BS and the configuration of DSCP specific for 16 ETS at the IP layer in the ASN Gateway and the HA/LMA/CR in the CSN. 17

18

7.15 ASN GW Selection and Load balancing 19

7.15.1 General 20 A WiMAX® ASN GW may support one or more functions selected on a per-MS basis. The selection of any ASN-21 GW within an ASN relies on the availability of R6 Flex support. 22

• Authenticator (per-MS Control Point anchor, identified by Authenticator ID), 23

The Authenticator is selected for an MS by the BS during MS Initial Network Entry process. 24

• Anchor GW (per-MS Data Path Anchor point, identified by Anchor GW ID). 25

Depending on t he r ole of ASN G W, di fferent mechanisms a re i nvolved i n the selection/ r e-selection 26 process. 27

During MS initial network entry, the Anchor GW for the MS is located in the same ASN-GW as the Authenticator 28 (i.e. Authenticator and Anchor GW are collocated). 29

7.15.2 ASN GW Selection and Load balancing 30 The R6 Flex feature allows a BS to maintain R6 associations with any ASN-GW within the same ASN. For the 31 purpose of ASN GW selection, the BS may be associated with one or multiple ASN GWs (called an ‘ASN-GW 32 cluster’) within i ts own ASN. During MS Initial Network Entry, the BS may select one of the ASN GWs from a 33 pool of available A SN GWs w ithin its A SN. Once A SN-GW s election d uring t he M S I NE p rocedures i s 34 successfully completed, the selected ASN-GW assumes the role of the Anchor Authenticator and the Anchor DP for 35 the MS. 36

The ASN-GW selection procedure in the BS is not specified by this specification and is left to implementation. 37

Some examples of ASN-GW selection include the following: 38

• ASN G W s election b y t he BS within a n ASN-GW c luster may be ba sed on a s imple “ round r obin” 39 algorithm or may be more complicated, e.g. based on ASN-GW availability and/or ASN-GW capacity/load 40 factor. 41

• A B S may be pre-configured with one or more ASN-GW clusters provided all of the ASN-GWs w ithin 42 these clusters belong to the same ASN as the BS. In this case, ASN-GW selection logic in a BS may be 43 based on a “cluster metric” or “cluster priority”). 44

45

Documents

WiMAX Forum Network Architecturewimaxforum.org/sites/wimaxforum.org/files/technical_document/2010/12/WMF-T32-001...Jul 03, 2012 · EXTENT P ERMITTED B Y LA W, TH E WiMAX FORUM14