Interfacing with a Kineto IP Network Controller
The Kineto IP Network Controller (INC) is the component of the Kineto UMA Network Controller (UNC) that manages subscriber access to voice and data mobile services. The Kineto INC-AAA (S1) interface Protocol Specification defines the interface requirements for communication between an AAA server and the Kineto INC. The following topics are included in this chapter:
The SIM authentication modules available with Steel-Belted Radius Carrier are designed to comply with the requirements for an AAA server. This chapter explains how these authentication modules interface with the Kineto INC and the tasks required for implementation.
Figure 23 illustrates the relationship between the Kineto INC and Steel-Belted Radius Carrier with one of the optional authentication modules.
Attribute Handling Methods
Attribute Handling Methods
The Kineto S1 Interface specification requires that certain Kineto vendor specific attributes (VSAs) be sent with Access-Requests, Access-Accepts, and Access-Rejects as defined in the following publicly available Kineto documents:
INC-AAA (S1) Interface Protocol Specification Version 4 (Revision 0.00)
UMA Service Access Control January 2006
The SIM authentication module available with Steel-Belted Radius Carrier are designed to comply with these specifications. Some of the Kineto VSAs contain structured attributes. Steel-Belted Radius Carrier can process these attributes in two different ways:
Native subattribute method— Steel-Belted Radius Carrier provides native support for structured attributes which contain subattributes. This is the recommended method when using the Kineto INC. Subattributes, like normal RADIUS attribute-value pair (AVPs), consist of the raw encoding of a type field (such as 1 for WiMAX-Release, within the WiMAX-Capability VSA) followed by a length value (such as 5) followed by the value of the attribute (such as 1.2). Subattributes are values in a RADIUS packet that are not stored as a RADIUS AVP, or vendor-specific-attribute (VSA), but rather are packed with other subattributes into a RADIUS VSA. In a RADIUS packet, there may be multiple RADIUS VSAs that contain subattributes. The RADIUS VSA, which consists of multiple subattributes, is sometimes referred to as a structured attribute because it contains structured data.
Refer to structured attributes, using the “.” notation. For example:
“A.b.c”
Where attribute “A” is a group attribute containing a sequence subattribute “b”, which contains a simple attribute “c”.
Structured attributes are addressable only by their full pathname, which must include all interim group or sequence attributes.
You do not need to add every subattribute in a tree. Steel-Belted Radius Carrier handles partially defined trees by automatically supplying subattributes that have a default value specified in the .jdict definition files. Additionally, if a subattribute is added that does not have a suitable parent or group defined, Steel-Belted Radius Carrier automatically creates one.
For complete details on subattributes, see Structured Attributes.
Flattening/Unflattening method— An Access-Request is processed by flattening the structured attribute into a single-payload. The subattributes contained in the structured attribute are copied out of their containing AVPs and represented in the Access-Request as if they had been received as separate AVPs. In the returned Access-Accept or Access-Reject messages, the structured Kineto VSAs are reassembled or unflattened before returning them to the Kineto INC device. Before release 7.0, this was the only method supported in Steel-Belted Radius Carrier. This flattening/unflattening method has been deprecated, and it is recommended that you migrate to the native subattribute method.
Table 213, Table 214, and Table 215 list the Kineto VSAs and their converted flattened/unflattened form, as well as their equivalent subattribute form. If you previously used the flatten/unflatten attribute conversion method, we recommend that you migrate to the subattribute method. All other Kineto attributes, not listed in the tables that follow, are passed between the Kineto INC and Steel-Belted Radius Carrier unchanged. If your processing requires handling of Kineto compound VSAs, use these conversion tables to identify the attributes to be passed between the Steel-Belted Radius Carrier AAA server and the Kineto INC.
Access-Request Conversion
Access-Request Conversion
Table 213 lists the Kineto Access-Request compound attributes that are flattened by Steel-Belted Radius Carrier with either the SIM authentication module.
Table 213: Conversion from Kineto VSAs to Flattened Attributes
Kineto Attribute Name | Size | Format Description | Converted to: Flattened or Subattribute |
---|---|---|---|
Kineto-UP-Client-Remote-Address | IPv4=8 IPv6=20 | Vendor-Type=2 octets Vendor-Length=1 octet IP Address Type=1 octet IP Address: 4 octets for IPv4 16 octets for IPv6 | Converted to one of the following two flattened attributes: Kineto-UP- or Kineto-UP-Client-Remote-IPv6-Addr Equivalent subattributes: Kineto-UP-Client-Remote-Address.IPv4-Address or Kineto-UP-Client-Remote-Address.IPv6-Address |
Kineto-UP-Client-Public-Address | IPv4=8 IPv6=20 | Vendor-Type=2 octets Vendor-Length=1 octet IP Address Type=1 octet IP Address: 4 octets for IPv4 16 octets for IPv6 | Converted to one of the following two flattened attributes: Kineto-UP-Clnt-Public-IPv4-Addr (type: ipaddr) or Kineto-UP-Clnt-Public-IPv6-Addr Equivalent subattributes: Kineto-UP-Client-Public-Address.IPv4-Address or Kineto-UP-Client-Public-Address.IPv6-Address |
Kineto-UMA-Classmark | 2 | Consists of multiple enumerated values within 2 octets. | Converted to all of the following four flattened attributes: Kineto-UMA-Classmark-TURA (type: integer) Kineto-UMA-Classmark-UC (type:integer) Kineto-UMA-Classmark-GC (type:integer) Kineto-UMA-Classmark-RRS (type:integer) Equivalent subattributes: Kineto-UMA-Classmark.TURA Kineto-UMA-Classmark.UC Kineto-UMA-Classmark.GC Kineto-UMA-Classmark.RTP-Redundancy- |
Kineto-UMA-AP-Radio-Identity | 7 | Discriminator octet (always 0x1) followed by 6-octet MAC address. | Converted to the following flattened attribute: Kineto-UMA-AP-Radio-MAC (type:string) Equivalent subattributes: Kineto-UMA-AP-Radio-Identity.Value |
Kineto-UMA-MS-Radio-Identity | 7 | Discriminator octet (always 0x1) followed by 6-octet MAC address. | Converted to the following flattened attribute: Kineto-UMA-MS-Radio-MAC (type:string) Equivalent subattributes: Kineto-UMA-MS-Radio-Identity.Value |
Kineto-UMA-Location-Area-ID | 5 if LAC is not present; 7 if LAC is present | Contains MCC (Mobile Country Code), MNC (Mobile Network Code) and LAC (Location Area Code). If the LAC is not present in the original VSA sent in the Access-Request, the attribute is not converted. The digits of MCC and MNC are encoded as BCD. MNC digit 3 may not be present, in which case its value is 0xF. See Figure 24 for an illustration of the encoding. | Converted to the following flattened attributes: Kineto-UMA-Location-Area-MCC (type:string) Kineto-UMA-Location-Area-MNC (type:string) Kineto-UMA-Location-Area-LAC (type:string) Equivalent subattributes: Note: The MCC and MNC (3 digit numbers) in Kineto-UMA-Location-Area-MCC and Kineto-UMA-Location-Area-MNC are now available as three separate integer subattributes (.MCC1, .MCC2, and so on.). Kineto-UMA-Location-Area-ID.MCC1 Kineto-UMA-Location-Area-ID.MCC2 Kineto-UMA-Location-Area-ID.MCC3 Kineto-UMA-Location-Area-ID.MNC1 Kineto-UMA-Location-Area-ID.MNC2 Kineto-UMA-Location-Area-ID.MNC3 Kineto-UMA-Location-Area-ID.LAC |
Kineto-UMA-Geographical-Loc |
| Two geographical location types can be generated:
For both geographical location types, a latitude and longitude
are generated from Kineto-UMA- | Converted to the following flattened attributes: Kineto-UMA-GeogLoc-Latitude Kineto-UMA-GeogLoc-Longitude Kineto-UMA-GeogLoc-Uncert-Circ (optional) Equivalent subattributes: Note: The subattribute equivalents for Kineto-UMA-Geographical-Loc have two possible structures: lat-long with uncertainty, or a lat-long alone. Note: The flattener method converts the latitude and longitude into decimal values to make them more readable and useful. The subattribute software does not process the attributes, it simply provides the Kineto-encoded values, which must be converted with reference to the Kineto specification if decimal degree values are desired. |
| The latitude and longitude are encoded in complex ways. For more information, see | Kineto-UMA-Geographical-Loc.Elipsiod- Kineto-UMA-Geographical-Loc.Elipsiod- Kineto-UMA-Geographical-Loc.Elipsiod- Kineto-UMA-Geographical-Loc.Elipsiod-Point- Kineto-UMA-Geographical-Loc.Elipsiod-Point- | |
|
| However, the converted latitude and longitude attribute formats must be encoded as ISO 6709 compliant string representations of decimal degrees, for example 48.0234. Note: Any number of decimal places for the degrees are accepted but the accuracy of the encoding depends on the format of the Kineto-UMA-Geographic al-Loc attribute. |
|
|
| Directions are expressed:
|
|
Kineto-UMA-Cell-Identity | 2 | 2-octet integer. | Before Release 7.0, the Kineto-UMA-Cell-Identity attribute was converted to a 4-octet integer, since Steel-Belted Radius Carrier did not handle 2-octet integers. In Steel-Belted Radius Carrier Release 7.0 and later, 2-octet integers are handled natively, so there is no need for using the flattening or subattribute method for this attribute. |
Kineto-UMA-AP-Service-Name | Number of octets in the string plus one | Consists of an octet discriminator followed by a string value of the PAN or SSID. PAN: Discriminator octet has a value of 0x02 and the PAN is the following string. IPv6: Discriminator octet has a value of 0x01 and the SSID is the following string. | Converted to the following flattened attributes: Kineto-UMA-AP-SSID (type:string) or Kineto-UMA-AP-PAN (type:string) Equivalent subattributes: Kineto-UMA-AP-Service-Name.SSID Kineto-UMA-AP-Service-Name.PAN |
Figure 24 illustrates the encoding for the Kineto-UMA-Location-Area-Identification attribute. This attribute contains the MCC (Mobile Country Code), MNC (Mobile Network Code) and LAC (Location Area Code). For more information see “Kineto-UMA-Location-Area-ID” in Table 213.
Access-Accept Conversion
Access-Accept Conversion
Table 214 describes the compound Kineto VSAs that are returned with Access-Accepts.
Table 214: Kineto Attributes Returned with the Access-Accepts
Converted From: Flattened or Subattributes | Returned Kineto Attribute (Unflattened) | Format Description |
---|---|---|
Converted from one of the following flattened attributes: Kineto-UMA-Service-Zone-Icon-Ind Kineto-UMA-Service-Zone-Name Subattribute equivalent: Kineto-UMA-Service-Zone-Info.Icon-Indicator Kineto-UMA-Service-Zone-Info.Name Kineto-UMA-Service-Zone-Info.Name-Length | Kineto-UMA-Service-Zone-Info | Consists of the Kineto-UMA-Service-Zone-Icon, followed by one octet containing the string length, followed by a string, extracted from Kineto-UMA-Service-Zone-Name. |
Converted from one of the following flattened attributes: Kineto-UMA-Location-Area-MCC Subattribute equivalent: Note: The MCC and MNC (3 digit numbers) in Kineto-UMA-Location-Area-MCC and Kineto-UMA-Location-Area-MNC are now available as three separate integer subattributes (.MCC1, .MCC2, and so on). Kineto-UMA-Location-Area-ID.MCC1 Kineto-UMA-Location-Area-ID.MCC2 Kineto-UMA-Location-Area-ID.MCC3 Kineto-UMA-Location-Area-ID.MNC1 Kineto-UMA-Location-Area-ID.MNC2 Kineto-UMA-Location-Area-ID.MNC3 Kineto-UMA-Location-Area-ID.LAC | Kineto-UMA-Location-Area-ID | Encoded values of Kineto-UMA-Location-Area-MCC, Kineto-UMA-Location-Area-MNC, and Kineto-UMA-Location-Area-LAC as shown in Figure 24. |
Converted from one of the following flattened attributes: Kineto-UMA-GeogLoc-Latitude Kineto-UMA-GeogLoc-Longitude Kineto-UMA-GeogLoc-Uncert-Circ(optional) Equivalent subattributes: Note: The subattribute equivalents for Kineto-UMA-Geographical-Loc have two possible structures: lat-long with uncertainty, or a lat-long alone. | Kineto-UMA-Geographical-Loc | Two geographical location types can be generated:
|
Note: The flattener method converts the latitude and longitude into decimal values to make them more readable and useful. The subattribute software does not process the attributes; it simply provides the Kineto-encoded values, which must be converted with reference to the Kineto specification if decimal degree values are desired. Kineto-UMA-Geographical-Loc.Elipsiod- Kineto-UMA-Geographical-Loc.Elipsiod- |
| For both geographical location types, a latitude and longitude are generated from Kineto-UMA- GeogLoc-Latitude and Kineto-UMA -GeogLoc-Longitude. The latitude and longitude are encoded in complex ways. For more information, see 3GPP TS 23.032, Sections 5 (Shapes), 6 (Coding), and 7 (General message format and information element). However, the converted latitude and longitude attribute formats must be encoded as ISO 6709 compliant string representations of decimal degrees DD.DDDD, for example 48.0234. |
Kineto-UMA-Geographical-Loc.Elipsiod- Kineto-UMA-Geographical-Loc.Elipsiod-Point- Kineto-UMA-Geographical-Loc.Elipsiod-Point- |
| Note: Any number of decimal places for the degrees are accepted but the accuracy of the encoding depends on the format of the Kineto-UMA-Geographical-Loc attribute. Directions are expressed:
For the second geographical type, the expected format of the uncertainty circle is a string that contains a decimal number of meters. For a full description of the uncertainty encoding and its forward translation, see 3GPP TS 23.032, Section 6.2 (Uncertainty). |
Access-Reject Conversion
Access-Reject Conversion
Table 215 describes the Kineto compound VSA that is returned with an Access-Reject.
Table 215: Kineto Attributes Returned with the Access-Response
Converted From: Flattened or Subattributes | Returned Kineto Attribute | Format Description |
---|---|---|
Converted from one of the following flattened attributes: Kineto-UMA-Service-Zone-Icon Kineto-UMA-Service-Zone-Name Equivalent subattributes: Kineto-UMA- Service -Zone-Info. Icon-Indicator Kineto- UMA-Service-Zone-Info.Name-Length | Kineto-UMA-Service-Zone-Information | Consists of the Kineto-UMA-Service-Zone-Icon-Ind, followed by one octet containing the string length, followed by a string, extracted from Kineto-UMA-Service-Zone-Name. |
Configuring the SIM Authentication Module for Handling Kineto Attributes
Configuring the SIM Authentication Module for Handling Kineto Attributes
The following configuration activities are required to activate Kineto attribute handling:
Configure the kinetoUMAAttrHandler.ctrl file (required only if using the flattening/unflattening attribute handling method)
Configure the controlpoints.ini file (required only if using the flattening/unflattening attribute handling method)
Configure Steel-Belted Radius Carrier to recognize the Kineto attributes
Develop applications for the S1 interface
Each of these configuration activities are described in the sections that follow.
Configuring the kinetoUMAAttrHandler.ctrl File
Configuring the kinetoUMAAttrHandler.ctrl File
The kinetoUMAAttrHandler.ctrl file (located in the Radius directory) calls the appropriate library, enables use of the Kineto attribute handling features, and controls related settings.
Configuration of the kinetoUMAAttrHandler.ctrl file is only required if using the flattening/unflattening attribute handling method. We recommend that you migrate to using the native subattribute handling method.
To configure the kinetoUMAAttrHandler.ctrl file:
Open the kinetoUMAAttrHandler.ctrl file located in the Radius directory.
In the [Bootstrap] section of the kinetoUMAAttrHandler.ctrl file, set Enable=1.
In the [Bootstrap] section of the kinetoUMAAttrHandler.ctrl file, make sure the following lines exist and are not commented out:
LibraryName=kinetoUMAAttrHandler.so
InitializationString= kinetoUMAAttrHandlerIn the [Settings] section of the kinetoUMAAttrHandler.ctrl file, make sure the following line exists and is not commented out:
RemoveTranslatedAttributes=true
Example kinetoUMAAttrHandler.ctrl file
[Bootstrap] Enable=1 LibraryName=kinetoUMAAttrHandler.so InitializationString= kinetoUMAAttrHandler [Settings] RemoveTranslatedAttributes=true
Table 216 explains the settings required in the kinetoUMAAttrHandler.ctrl file to allow Kineto attribute handling.
Table 216: kinetoUMAAttrHandler.ctrl Fields
Section | Field | Description |
---|---|---|
[Bootstrap] | LibraryName | Specifies the name of the executable binary. Set to kinetoUMAAttrHandler.so |
[Bootstrap] | Enable |
Set to 1. |
[Bootstrap] | InitializationString | Specifies the name of the initialization file for the library. Set to kinetoUMAAttrHandler |
[Settings] | Remove Translated Attributes |
Set to true. |
Configuring the controlpoints.ini File
Configuring the controlpoints.ini File
The controlpoints.ini file (located in the Radius directory) calls the attribute handler at the appropriate processing stages.
Configuration of the controlpoints.ini file is only required if using the flattening/unflattening attribute handling method. We recommend that you migrate to using the native subattribute handling method.
To configure the controlpoints.ini file:
Open the controlpoints.ini file located in the Radius directory.
Enter the following lines in the file:
[Auth-Initial-Request]
kinetoUMAAttrHandler
[Auth-Final-Request]
kinetoUMAAttrHandler
Table 217 explains the settings required in the controlpoints.ini file to allow Kineto attribute handling.
Table 217: controlpoint.ini File Settings
Field | Description |
---|---|
[Auth-Initial-Request] section | Calls the attribute handler plug-in when the initial authorization request is received. Add the field: kinetoUMAAttrHandler |
[Auth-Final-Request] section | Calls the attribute handler plug-in when authorization is complete. Add the field: kinetoUMAAttrHandler |
Configuring Kineto Attribute Recognition
Configuring Kineto Attribute Recognition
You must configure SBR Carrier to recognize the Kineto attributes by loading the Kineto dictionary file (.dct file).
To configure SBR Carrier to recognize the Kineto attributes you need to configure Kineto as a RADIUS client and activate the authentication method you want to use with Kineto using the Web GUI:
Launch the Web GUI and log in to your SBR Carrier server.
Select RADIUS Configuration > RADIUS Clients.
The RADIUS Clients List page (Figure 25) appears.
Click Add.
The Create RADIUS Client pane (Figure 26) appears with the Basic Configuration tab selected.
Select Kineto S1 from the Make or Model list and enter other details for your Kineto INC
Note Selection of Kineto S1 from the Make or Model list causes the Kineto dictionary file (.dct file) to be applied, which includes the Kineto attributes.
Click Save to save the changes.
The RADIUS Clients List page (Figure 28) lists the Kineto INC entry.
Activating the Authentication Method
Activating the Authentication Method
To use either LDAP or SQL authentication, follow the procedures in the section on back-end authentication and accounting in the SBR Carrier Administration and Configuration Guide and see Back-End Authentication and Accounting. To use the LDAP authentication method, you need to configure the ldapauth.aut file. To use the SQL authentication method you need to configure either the radsql.aut or radsqljdbc.aut file. After these files are configured, the respective authentication method becomes available to activate in Web GUI.
To activate the authentication method using the Web GUI:
Select RADIUS Configuration > Authentication Policies > Order of Methods.
The Authentication Methods page Figure 29 displays any configured authentication methods in the server. The Inactive Authentication Methods area displays a list of inactive authentication methods, while the Active Authentication Methods area displays a list of active authentication methods.
Select the authentication method from the Inactive Authentication Methods area and click the Right arrow.
You can also activate the authentication method by dragging the method to the right.
Note The name of the LDAP or SQL authentication method is specified in the InitializationString parameter of the .aut file. In the example shown in Figure 29, the MYSQL_JDBC was defined in the radsqljdbc.aut. The authentication method does not appear in the list of authentication methods until you configure the associated .aut file.
To change the order in which the server tries authentication methods, select each authentication method and click the Up or Down arrow until the authentication methods are in the desired order.
Click Save to save the changes.
Developing Applications for the S1 Interface
Developing Applications for the S1 Interface
To implement the Kineto S1interface with the authentication modules, you must:
Write your application using SQL stored procedures or LDAP scripting to conform with the requirements in the Kineto S1 interface specification.
Configure and enable the ldapauth.aut, or radsql.aut or radsqljdbc.aut to authenticate subscribers using data stored in an LDAP directory or an SQL database.
For more information about SQL stored procedures, LDAP scripting, the LDAP authentication plug-in: ldapauth.aut, or the SQL plug-ins: radsql.aut or radsqljdbc.aut, see Back-End Authentication and Accounting in this guide. Also see information about creating LDAP scripts and back-end authentication and accounting methods in the SBR Carrier Administration and Configuration Guide.