close
Warning:
Can't synchronize with repository "(default)" (/common/SVN/wimax does not appear to be a Subversion repository.). Look in the Trac log for more information.
- Timestamp:
-
Dec 9, 2010, 7:31:11 PM (13 years ago)
- Author:
-
hmussman
- Comment:
-
—
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v10
|
v11
|
|
1 | | [[TOC(Internal/WiMAX/WiMAXAPI*, depth=2)]] |
| 1 | [[PageOutline]] |
2 | 2 | |
3 | 3 | = A. APIs = |
4 | 4 | |
5 | | == A.1 API Classification and Usage == |
| 5 | == A.1 API Classification == |
6 | 6 | |
7 | 7 | |
8 | 8 | The APIs are primarily classified as: |
9 | 9 | * User exposed |
10 | | * [wiki:WiMAX/16/3 Slice management service] |
11 | | * [wiki:WiMAX/16/4 Radio management service] |
| 10 | * [wiki:WiMAX/55 Slice management service] |
| 11 | * [wiki:WiMAX/57 Radio management service] |
12 | 12 | |
13 | 13 | * Internal |
14 | | * [wiki:WiMAX/16/1 System Administration API] |
15 | | * [wiki:WiMAX/16/5 SM-Datapath API] |
| 14 | * [wiki:WiMAX/50 System Administration API] |
| 15 | * [wiki:WiMAX/59 SM-Datapath API] |
16 | 16 | * [wiki:WiMAX/WiMAXAPI/05RMDpApi RM-Datapath API] |
17 | 17 | * [wiki:WiMAX/WiMAXAPI/06BSFBDpApi BSFB-Datapath API] |
… |
… |
|
25 | 25 | * setters – responsible for setting the specified control information. |
26 | 26 | |
27 | | === A.1.1 Sample Experiment Setup Using API === |
| 27 | == A.2 API Usage == |
| 28 | |
| 29 | === A.2.1 Sample Experiment Setup Using API === |
28 | 30 | |
29 | 31 | A sample usage of the API for experiment setup is as shown in the Figure below. |
… |
… |
|
38 | 40 | The addclient() API has an optional service class parameter that the user can specify. If the user does not specify the service class id, a default service class is allocated that has a single best effort type of service flow. After this sequence is complete, the user can direct traffic to the local virtual interface in the VM with the appropriate MAC address, and traffic will be automatically sent to the correct wireless client. |
39 | 41 | |
40 | | === A.1.2 Sample Experiment: Custom Service Class Control === |
| 42 | === A.2.2 Sample Experiment: Custom Service Class Control === |
41 | 43 | To demonstrate how the user could possibly create custom service classes we show an |
42 | 44 | example of how system components will interact in the Figure below. |
… |
… |
|
48 | 50 | |
49 | 51 | |
50 | | == A.2 System Administrator API Specification (Internal) == |
| 52 | == A.3 System Administrator API Specification (Internal) == |
51 | 53 | These set of functions are exposed to the system administrator for managing and monitoring slice quotas from a virtualization perspective. More administrative functionality is provided on the RF side as discussed in the BS-RF API. |
52 | 54 | |
53 | | === A.2.1 VM Administration === |
54 | | |
55 | | === setSliceParams(SLICEID, disk_quota, cpu) === |
| 55 | === A.3.1 VM Administration === |
| 56 | |
| 57 | ==== setSliceParams(SLICEID, disk_quota, cpu) ==== |
56 | 58 | - This function is provided to the administrator for setting up slice level parameters such as total disk / cpu quota assigned to a slice. |
57 | 59 | - Successful setting of these parameters returns “ok” |
58 | | === getSliceParams(SLICEID) === |
| 60 | |
| 61 | ==== getSliceParams(SLICEID) ==== |
59 | 62 | - This function is provided to the administrator for getting slice level parameters such as total disk/CPU quota assigned to a slice. |
60 | 63 | - Online information such as current usage is also be made available. |
61 | 64 | - Returns XML with appropriate parameters on success, “nok” otherwise. |
62 | | == getTotalParams(SLICEID) === |
| 65 | |
| 66 | ==== getTotalParams(SLICEID) ==== |
63 | 67 | - This function is provided to the administrator for getting information on total available resources, such as disk space/ cpu quota available for allocation. |
64 | 68 | - This function is typically used by the administrator before the use of setSliceParams() function. |
65 | 69 | - Returns XML with appropriate parameters on success, “nok” otherwise. |
66 | 70 | |
67 | | = Slice Manager API Specification (User Exposed) = |
| 71 | == A.4 Slice Manager API Specification (User Exposed) == |
68 | 72 | |
69 | 73 | The slice manager API are further classified into |
… |
… |
|
71 | 75 | 2. Client control functions. |
72 | 76 | |
73 | | == SLICE (VM) Control Functions == |
| 77 | === A.4.1 SLICE (VM) Control Functions === |
74 | 78 | |
75 | 79 | These set of functions are responsible for managing context isolation of multiple slices through the use of virtual machines. |
76 | 80 | |
77 | | === createSLICE === |
| 81 | ==== createSLICE ==== |
78 | 82 | This function is invoked from a gateway machine by the slice user to instantiate its slice for experimentation. |
79 | 83 | |
… |
… |
|
90 | 94 | }}} |
91 | 95 | |
92 | | === destroySLICE === |
| 96 | ==== destroySLICE ==== |
93 | 97 | This function is used to destroy instance of the SLICE for which IP is assigned; slice is destroyed only after authentication of the used_id and passwd. |
94 | 98 | |
… |
… |
|
100 | 104 | }}} |
101 | 105 | |
102 | | === startSLICE === |
| 106 | ==== startSLICE ==== |
103 | 107 | This function is used to start the slice for which IP is assigned; can be invoked only after the the createSLICE() call is made and is successful only if the instance is owned by the issuing user. . |
104 | 108 | |
… |
… |
|
108 | 112 | }}} |
109 | 113 | |
110 | | === stopSLICE === |
| 114 | ==== stopSLICE ==== |
111 | 115 | This function is used to stop the instance of the SLICE for which IP is assigned (SLICE instance is stopped only if the instance is owned by the issuing user). |
112 | 116 | {{{ |
… |
… |
|
115 | 119 | }}} |
116 | 120 | |
117 | | === setSLICEParams === |
| 121 | ==== setSLICEParams ==== |
118 | 122 | Allows the user to set all controllable parameters for creation of SLICE. Features include the amount of disk space per SLICE template, percentage of CPU resources (number of parameters supported as a part of this API may vary with underlying virtualization technology). |
119 | 123 | {{{ |
… |
… |
|
122 | 126 | }}} |
123 | 127 | |
124 | | == Client Control Functions == |
| 128 | === A.4.2 Client Control Functions === |
125 | 129 | |
126 | 130 | These set of functions allow the datapath controller to determine which WiMAX clients can associate with the BTS and vice-versa. These API are internal and are based on the input provided by the slice user. |
127 | 131 | |
128 | | === addClient === |
| 132 | ==== addClient ==== |
129 | 133 | This function is called by the user to add a client with MAC address MSID to the slice SliceID. |
130 | 134 | {{{ |
… |
… |
|
133 | 137 | }}} |
134 | 138 | |
135 | | === deleteClient === |
| 139 | ==== deleteClient ==== |
136 | 140 | Used to remove client with MAC address MSID from the slice with identifier as Slice ID. |
137 | 141 | {{{ |
… |
… |
|
141 | 145 | |
142 | 146 | |
143 | | = Radio Management API (User Exposed) = |
| 147 | == A.5 Radio Management API (User Exposed) == |
144 | 148 | |
145 | 149 | These API define the calls that can be made by the system user for controlling radio-related features of the WiMAX system. These API are further classified based on the functionality they provide. |
146 | | == Custom Service Class Suport == |
| 150 | |
| 151 | === A.5.1 Custom Service Class Support === |
147 | 152 | These APIs will allow the user to create user-defined service flow types apart from the 5 standard service flows supported as a part of the current model. |
148 | | === createServiceFlow(SlideID, direction, priority, classifier-ips, classifier-ports, service_type, service_params) === |
| 153 | ==== createServiceFlow(SlideID, direction, priority, classifier-ips, classifier-ports, service_type, service_params) ==== |
149 | 154 | - Direction – Uplink or downlink for the class. |
150 | 155 | - Priority – priority of the service class |
… |
… |
|
156 | 161 | - Note that the service type is created by the Radio management grid service for |
157 | 162 | a specific slice ID and hence it will be specific to that slice. |
158 | | === createServiceClass(SlideID,STIDs{}) === |
| 163 | ==== createServiceClass(SlideID,STIDs{}) ==== |
159 | 164 | - SliceID identifies the requesting slice. |
160 | 165 | - STIDs are the service type ids. |
161 | 166 | - Success returns the Service class ID (SCID), which can be used in install or remove. |
162 | | === installServiceClass(SlideID,SCID) === |
| 167 | ==== installServiceClass(SlideID,SCID) ==== |
163 | 168 | - SliceID identifies the requesting slice. |
164 | 169 | - Installs all the service flows that are part of the service class SCID. |
165 | 170 | - Success results in end – to – end datapath setup between wireless clients and virtual machine slice. |
166 | | === uninstallServiceClass(SlideID,SCID) === |
| 171 | ==== uninstallServiceClass(SlideID,SCID) ==== |
167 | 172 | - SliceID identifies the requesting slice. |
168 | 173 | - Un-installs all the service flows that are part of the service class SCID. |
169 | 174 | - Success returns ok and nok otherwise. |
170 | 175 | |
171 | | === deleteServiceClass(SlideID, SCID) === |
| 176 | ==== deleteServiceClass(SlideID, SCID) ==== |
172 | 177 | - Deletes the service class corresponding to the specification in the request. |
173 | 178 | - Returns success if the service class could be successfully deleted (none of the |
174 | 179 | flows are actively using these service classifiers). |
175 | 180 | |
176 | | === deleteServiceFlow(SlideID, STID) === |
| 181 | ==== deleteServiceFlow(SlideID, STID) ==== |
177 | 182 | - Results in deletion of service flow type identified by STID if any such flow type exists. |
178 | 183 | - Success results in “ok” and “nok” otherwise. |
179 | 184 | |
180 | 185 | |
181 | | == Slice Radio Control == |
182 | | |
183 | | === setMinimalMcs(SliceID, MSID, SCID, mcs) === |
| 186 | === A.5.2 Slice Radio Control === |
| 187 | |
| 188 | ==== setMinimalMcs(SliceID, MSID, SCID, mcs) ==== |
184 | 189 | - Used to set the minimal modulation and coding scheme (MCS) to be used for |
185 | 190 | that service class. An auto rate provision will select a better MCS based on the |
… |
… |
|
189 | 194 | current understanding, this is difficult. |
190 | 195 | |
191 | | === setFixedMcs(SliceID, MSID, SCID, mcs) === |
| 196 | ==== setFixedMcs(SliceID, MSID, SCID, mcs) ==== |
192 | 197 | - Used to set a fixed MCS for a particular service class. |
193 | 198 | - This disables the automatic MCS adjustment using measured CINR. |
194 | 199 | - If possible we wish to set this mcs value per MSID. |
195 | 200 | |
196 | | === setRadioResource(SliceID, MSID, RR) === |
| 201 | ==== setRadioResource(SliceID, MSID, RR) ==== |
197 | 202 | - Information provided by this function should be consulted during initial ranging and connection setup. |
198 | 203 | - RR – Radio resource uplink + downlink (set in % - 0 to 100) |
199 | 204 | |
200 | | === setBandwithUlDlRatio(bandwidth UL_DL_ratio) === |
| 205 | ==== setBandwithUlDlRatio(bandwidth UL_DL_ratio) ==== |
201 | 206 | - Set supported bandwidth: 10M, 7.5M, 5M Hz |
202 | 207 | - Based on RR allocation in set_radio_resource(), this routine allows the user to set |
… |
… |
|
204 | 209 | - UL_DL_ratio is used as a key to select one among standard UL_DL ratio supported by the BS. All MS has to use the same ul_dl_ratio |
205 | 210 | |
206 | | == Slice Radio Monitoring == |
207 | | |
208 | | === getAllClientsInfo( SLICEID ) === |
| 211 | === A.5.3 Slice Radio Monitoring === |
| 212 | |
| 213 | ==== getAllClientsInfo( SLICEID ) ==== |
209 | 214 | - Returns the number of WiMAX clients associated with a particular SLICEID. |
210 | 215 | - Return value ranges between 0 and maximum number of clients that can be owned by a slice on success, “nok” otherwise |
211 | 216 | |
212 | | === getClientInfo(SLICE ID, MSID) === |
| 217 | ==== getClientInfo(SLICE ID, MSID) ==== |
213 | 218 | - Returns detailed information about a single client in the network. |
214 | 219 | - Information for individual MAC address includes the amount of disk quota, disk space used, and the CPU quota (reserved and used). |
215 | 220 | - Returns XML with appropriate parameters on success, “nok” otherwise |
216 | 221 | |
217 | | === getSliceResource(SLICEID) === |
| 222 | ==== getSliceResource(SLICEID) ==== |
218 | 223 | - This mechanism allows every slice to monitor its current usage, and the limits |
219 | 224 | - Values returned may vary based on the virtualization technology used - (disk space, CPU). |
… |
… |
|
221 | 226 | |
222 | 227 | |
223 | | = SM – Datapath API (Internal) = |
| 228 | == A.6 SM – Datapath API (Internal) == |
224 | 229 | |
225 | 230 | These set of API are responsible for dealing with the datapath creation after slice initialization and client registration. |
226 | | === addClient(VLAN, MSID) === |
| 231 | ==== addClient(VLAN, MSID) ==== |
227 | 232 | - This function is invoked by the slice manager after the user requests it to add a client to the slice. |
228 | 233 | - The slice manager looks up the appropriate VLAN tag number and requests that the MAC MSID of the mobile client be added to the VLAN. |
229 | 234 | - This API facilitates half of the datapath creation, which will be completed when the MSID associates with the system. |
230 | 235 | |
231 | | === removeClient(VLAN, MSID) === |
| 236 | ==== removeClient(VLAN, MSID) ==== |
232 | 237 | - Compliments the addClient() function. |
233 | 238 | - On the execution of this call the datapath manager removes the mapping from the slice virtual machine to the wireless mobile client. |