Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

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.

Figure 23: Communication Between Kineto INC and Steel-Belted Radius Carrier

Communication Between Kineto INC and
Steel-Belted Radius Carrier

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 216, Table 217, and Table 218 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

Table 216 lists the Kineto Access-Request compound attributes that are flattened by Steel-Belted Radius Carrier with either the SIM authentication module.

Table 216: Conversion from Kineto VSAs to Flattened Attributes

Kineto Attribute Name

Size
in Octets

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-
Client-Remote-IPv4-Addr (type: ipaddr)

or

Kineto-UP-Client-Remote-IPv6-Addr
(type: ipv6addr)

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
(type: ipv6addr)

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-
Supported

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:

  • ellipsoid point (discriminator=0x00, length=7) for a latitude and longitude without any uncertainty.
  • ellipsoid point with uncertainty circle (discriminator=0x10, length=8) if Kineto-UMA-
    GeogLoc-Uncert-Circ is present.

For both geographical location types, a latitude and longitude are generated from Kineto-UMA-
GeogLoc-Latitude and Kineto-UMA
-GeogLoc-Longitude.

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-
Point.Latitude

Kineto-UMA-Geographical-Loc.Elipsiod-
Point-With-Uncertainty.Latitude

Kineto-UMA-Geographical-Loc.Elipsiod-
Point.Longitude

Kineto-UMA-Geographical-Loc.Elipsiod-Point-
With-Uncertainty.Longitude

Kineto-UMA-Geographical-Loc.Elipsiod-Point-
With-Uncertainty.Uncertainty

 

 

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:

  • northern latitudes—positive numbers
  • southern latitudes—negative numbers
  • east longitudes—positive numbers
  • west longitudes—negative numbers

 

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 216.

Figure 24: Format of Kineto-UMA-Location-Area-Identification Attribute

Format of Kineto-UMA-Location-Area-Identification
Attribute

Access-Accept Conversion

Table 217 describes the compound Kineto VSAs that are returned with Access-Accepts.

Table 217: 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
Kineto-UMA-Location-Area-MNC
Kineto-UMA-Location-Area-LAC

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:

  • ellipsoid point (discriminator=0x00, length=7) for a latitude and longitude without any uncertainty.
  • ellipsoid point with uncertainty circle (discriminator=0x10, length=8) if Kineto-UMA-
    GeogLoc-Uncert-Circ is present.

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-
Point.Latitude

Kineto-UMA-Geographical-Loc.Elipsiod-
Point-With-Uncertainty.Latitude

 

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-
Point.Longitude

Kineto-UMA-Geographical-Loc.Elipsiod-Point-
With-Uncertainty.Longitude

Kineto-UMA-Geographical-Loc.Elipsiod-Point-
With-Uncertainty.Uncertainty

 

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:

  • northern latitudes—positive numbers
  • southern latitudes—negative numbers
  • east longitudes—positive numbers
  • west longitudes—negative numbers

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

Table 218 describes the Kineto compound VSA that is returned with an Access-Reject.

Table 218: 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

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

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.

Note: 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:

  1. Open the kinetoUMAAttrHandler.ctrl file located in the Radius directory.
  2. In the [Bootstrap] section of the kinetoUMAAttrHandler.ctrl file, set Enable=1.
  3. In the [Bootstrap] section of the kinetoUMAAttrHandler.ctrl file, make sure the following lines exist and are not commented out:

    LibraryName=kinetoUMAAttrHandler.so
    InitializationString= kinetoUMAAttrHandler

  4. In 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 219 explains the settings required in the kinetoUMAAttrHandler.ctrl file to allow Kineto attribute handling.

Table 219: kinetoUMAAttrHandler.ctrl Fields

Section

Field

Description

[Bootstrap]

LibraryName

Specifies the name of the executable binary.

Set to kinetoUMAAttrHandler.so

[Bootstrap]

Enable

  • Set to 1 to enable this file.
  • Set to 0 to disable this file.

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 to enable this file.
  • Set to false to disable this file.

Set to true.

Configuring the controlpoints.ini File

The controlpoints.ini file (located in the Radius directory) calls the attribute handler at the appropriate processing stages.

Note: 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:

  1. Open the controlpoints.ini file located in the Radius directory.
  2. Enter the following lines in the file:

    [Auth-Initial-Request]
    kinetoUMAAttrHandler
    [Auth-Final-Request]
    kinetoUMAAttrHandler

Table 220 explains the settings required in the controlpoints.ini file to allow Kineto attribute handling.

Table 220: 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

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:

  1. Launch the Web GUI and log in to your SBR Carrier server.
  2. Select RADIUS Configuration > RADIUS Clients.

    The RADIUS Clients List page (Figure 25) appears.

    Figure 25: RADIUS Clients List Page

    RADIUS Clients List
Page
  3. Click Add.

    The Create RADIUS Client pane (Figure 26) appears with the Basic Configuration tab selected.

    Figure 26: Create RADIUS Client Pane—Basic Configuration

    Create
RADIUS Client Pane—Basic Configuration
  4. 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.

    Figure 27: Selection of Kineto S1 from Make or Model List

    Selection of Kineto S1 from Make or Model List
  5. Click Save to save the changes.

    The RADIUS Clients List page (Figure 28) lists the Kineto INC entry.

    Figure 28: RADIUS Clients List page with Kineto Entry

    RADIUS
Clients List page with Kineto Entry

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:

  1. 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.

    Figure 29: Authentication Methods Page

    Authentication
Methods Page
  2. 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.

  3. 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.
  4. Click Save to save the changes.

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.

 

Modified: 2017-03-07