Differentiated Services Code Point (DSCP) levels can be assigned to specific traffic patterns in order to ensure that data packets are delivered according to the precedence with which they are tagged. The DiffServ markings are applied to the IP header for every subscriber data packet transmitted in the downlink direction to the WLAN access network. The four traffic patterns have the following order of precedence:

In addition, for class type Interactive, further categorization is done in combination with traffic handling priority and allocation-retention priority. Data packets falling under the category of each of the traffic patterns are tagged with a DSCP marking. Each traffic class is mapped to a QCI value according to mapping defined in TS 23.203. Therefore, DSCP values must be configured for different QCI values.

DSCP markings can be configured to control the DSCP markings for downlink packets. The IP header of the packet is updated with the value in TOS field. Note that there is no tunnel at the access side in SaMOG Gateway, hence the TOS field in the subscriber IP packet is marked with the DSCP value directly.

For more information on DSCP Marking on the SaMOG Gateway, refer DSCP Marking.

The SaMOG Gateway's CGW service supports GTPUv1 towards the P-GW as defined in 3GPP TS 29.281, V11, including the following functions:

The SaMOG Gateway's CGW service supports the GTPv2/GTPv1-based S2a/Gn interface towards the GGSN/P-GW for session establishment per 3GPP TS 29.274 and 29.060 Release 11.5, including the following functions:

The SaMOG Gateway's CGW service supports dynamic per-session Generic Routing Encapsulation (GRE) tunnels from the trusted 3GPP WLAN per RFC 5845.

During LTE-to-WiFi mobility, the SaMOG Gateway's CGW service selects the same P-GW that anchored the session over LTE. The CGW service selects the GGSN/P-GW via an internal trigger from the SaMOG Gateway's MRME service.

The SaMOG Gateway's CGW service provides the underlying mechanism to terminate per-session Proxy Mobile IP (PMIPv6) tunnels from the WLAN infrastructure. To accomplish this, the CGW service acts as an Local Mobility Anchor (LMA) towards the Wireless LAN Controllers (WLCs), which acts as a Mobile Access Gateway (MAG) with PMIPv6 functionality as defined in RFC 5213. The LMA and MAG functions use Proxy Mobile IPv6 signaling to provide network-based mobility management on behalf of the UEs attached to the network. With this approach, the attached UEs are no longer involved in the exchange of signaling messages for mobility.

The LMA function on the SaMOG Gateway's CGW service and the MAG function on the WLCs maintain a single shared tunnel. To distinguish between individual subscriber sessions, separate GRE keys are allocated in the Proxy-MIP Binding Update (PBU) and Proxy-MIP Binding Acknowledgement (PBA) messages between the CGW service and the WLCs. To handle AAA server initiated disconnections, the CGW service supports RFC 5846 for Binding Revocation Indication (BRI) and Binding Revocation Acknowledgement (BRA) messaging with the WLCs.

CGW connects 3G/4G subscribers to EPC/Internet through the Trusted Wifi SSIDs served by EoGRE enabled Residential Gateways. CGW acts as the tunnel endpoint for the EoGRE tunnel initiated from the Residential Gateway. With the use of SSID-based WLAN access, the subscribers are authenticated based on the SSID they use in order to connect to the WLAN. The Residential-GW/WLC maintains a separate SSID for providing the 3G/4G access to help the UE in selecting the correct SSID for obtaining 3G/4G access through Wifi network. SaMOG (MRME) act as the AAA server and DHCP server for the UE attaching to the WLAN network. This helps in processing all the control packets from the UE and maintaining the subscriber session to provide 3G/4G access. While acting as DHCP-Server, CGW creates the PDP-Context with GGSN/P-GW to obtain the IP Address to be allocated to UE through DHCP-Response in the access side. The DHCP and data packets generated by UE will be tunneled over EoGRE by Residential-GW/WLC node to SaMOG.

In StarOS Release 18 and later, the SaMOG Gateway can connect to the P-GW service over the S2a interface based on the PMIPv6 protocol as specified by 3GPP TS 29.275, Release 11 standards. The SaMOG Gateway performs a SNAPTR-based DNS query towards the DNS server to get the P-GW IP address, and initiates a PMIPv6-based registration procedure (acting as a Mobile Access Gateway (MAG)) by sending a Proxy Binding Update message to the P-GW. The IP address of the User Equipment (UE) allocated by P-GW (acting as the Local Mobility Anchor (LMA)) is then received in the Proxy Binding Acknowledge message.

How S2a Interface using PMIPv6 Works

The UE performs an 802.11 initial attach procedures and connect to Access Points (AP) and Wireless LAN Controllers (WLC), which in turn triggers a RADIUS-based authentication with the SaMOG Gateway. The SaMOG Gateway selects a RADIUS/Diameter-based AAA server or AAA proxy based on the local profile configuration and performs a RADIUS/Diameter-based authentication with the AAA server. After multiple rounds of authentication, the AAA server confirms the authentication status for the UE and shares the subscriber profile with the SaMOG Gateway. The SaMOG Gateway selects the P-GW based on the subscribers authorization information and setup a PMIPv6-based session with the P-GW. The data between the SaMOG Gateway and P-GW are exchanged through GRE tunnels using GRE keys for uplink and downlink data.

Limitations

The following are the current limitations for the SaMOG S2a interface using PMIPv6:

The SaMOG Gateway's MRME service supports Extensible Authentication Protocol (EAP) over RADIUS to interact with the WLCs for authenticating the WLAN UEs based on RFC 3579. Two attributes, EAP-Message and Message-Authenticator, are used to transport EAP messages as defined in RFC 3579. The MRME service validates and processes these messages as follows:

The SaMOG Gateway supports the use of the EAP identity of the Decorated NAI in the following format:

homerealm!username@otherrealm

The username part of the Decorated NAI complies with RFCs 4187, 4816, and 5448 for EAP AKA, EAP SIM, and EAP AKA', respectively.

The SaMOG Gateway's MRME service supports the use of the EAP identity of the Emergency NAI in the following format:

0<IMSI>@sos.wlan.mnc015.mcc234.3gppnetwork.org/1<IMSI>@sos.wlan.mnc015.mcc234.3gppnetwork.org

If the IMSI is not available, the Emergency NAI can include the IMEI/MAC address, as follows:

As per RFC 29.273, UEs without an IMSI are not authorized via the STa Interface. If the Emergency NAI includes an IMEI or MAC username format, the authentication request will be rejected.

Where the AAA server supports fast reauthentication, the AAA server assigns an identity to the subscriber which is used by the subscriber's UE to initiate a reattach or reauthentication. This authentication method is faster than the full reauthentication method as the AAA server and UE use the authentication key from a previous full authentication. The UE sends the assigned fast reauthentication NAI for subsequent authentication attempts, and the AAA server looks up the mapping between the fast reauthentication NAI and the identity of the subscriber.

The SaMOG gateway supports the use of the EAP identity of the Fast Reauthentication NAI in the following normal and decorated formats:

Normal: <prefix+fast-reauth-id>@nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org

Decorated: nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org!<prefix+fast-reauth-id>@nai.epc.mnc<visitedMNC> .mcc<visitedMCC>.3gppnetwork.org

The fast-reauth-id part of the Fast Reauthentication NAI complies with 3GPP 23.003 standards.

The following are examples of a typical NAI:

The pseudonym NAI is a temporary identity provided to a user by the AAA server that the subscriber uses while connecting to the network. This enables the subscriber to connect and authenticate without revealing their IMSI information on the network. The AAA server maintains a mapping between the real identity and the pseudonym NAI of the subscriber, and uses the mapping to identify the subscriber.

The SaMOG gateway supports the use of the EAP identity of the Pseudonym NAI in the following normal and decorated formats:

Normal: <prefix+pseudonym-id>@nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org

Decorated: nai.epc.mnc<homeMNC>.mcc<homeMCC>.3gppnetwork.org!<prefix+pseudonym-id>@nai.epc.mnc<visitedMNC> .mcc<visitedMCC>.3gppnetwork.org

The pseudonym-id part of the Pseudonym NAI complies with 3GPP 23.003 standards.

The following are examples of a typical NAI:

The SaMOG Gateway supports the use of the EAP identity of the Root NAI in the following format:

username@otherrealm

The username part of the Root NAI complies with RFCs 4187, 4816, and 5448 for EAP AKA, EAP SIM, and EAP AKA', respectively.

The following are examples of a typical NAI:

The SaMOG Gateway additionally supports EAP-based authentication where the inner layer of EAP protocols is agnostic. This enables SaMOG to support authentication mechanisms such as EAP-TLS and EAP-TTLS/MSCHAPv2, to connect non-UICC devices to the EPC core.

EAP-TLS

This authentication mechanism enables SaMOG to provide a certificate-based mutual authentication mechanism between the UE and the EAP Server for non-UICC devices.

EAP-TTLS/MSCHAPv2

SaMOG performs this authentication mechanism in two phases. During the first phase, SaMOG authenticates the server using a certificate that is used to create a secure tunnel. In the second phase, the subscriber is authenticated using MSCHAPv2 authentication mechanism within the secure tunnel.

Authentication

SaMOG considers the EAP-response/identity messages between the WLC and the AAA server as an uncategorized EAP authentication mechanism. SaMOG allows messages to be exchanged until a success/failure message is received from the AAA server, or the session setup timer expires.

NAI Usage

As with SIM-based authentications, in compliance to 3GPP 23.003 standard, SaMOG expects the NAI forwarded by the UE to be in the same format for P-GW selection, with the flexibility to support non-IMSI-based user-name in the AVP.

If the prefix for the user-name is uncategorized (not between 0 and 9), SaMOG considers the username portion of the NAI as non-IMSI based.

In StarOS Release 18 and later, the SaMOG Gateway can receive the User Equipment's (UE) MAC address as the UE's identity in the Calling-Station-ID AVP in the Radius message (Access-Request). The UE's identity can then be forwarded over the GTPv1 or GTPv2 interface in the IMEI Software Version (SV) IE to GGSN, or Mobile Equipment Identity (MEI) IE to P-GW.

As the UE identity (MAC address) is 12 Bytes long (6 Bytes in the TBCD format), and the total length of the IMEIsV is 8 bytes, the additional 2 Bytes can be padded with an user configurable filler value.

In StarOS Release 18 and later, the SaMOG Gateway can share the location information of the AP in the User Location Information (ULI) IE during the PDP context setup, and update the locations as Update Context Requests on the GTPv1 interface.When SaMOG detects a change in the AP's location during handovers, an Update PDP Context message is triggered.

SaMOG supports a new format to facilitate AP location in the Called-Station-ID AVP forwarded in the Radius messages. APs are assigned AP-Names which contain the location details and its MAC address (identity). The AP location (CGI) consists of the Location Area Code (LAC) and the Cell Identity (CI). SaMOG supports the following formats in the Called-Station-ID AVP:

For example, if an AP is assigned LAC = 1235, CI = 6789, AP-MAC = 11-22-33-44-55-66, and SSID = test, the Called-Station-ID AVP will contain cgi<12356789>:mac<112233445566>:test.

The SaMOG Gateway supports access point (AP) group name format in the Called-Station-ID AVP to enable a way to apply policies based on WiFi AP groups . The AP/WLC forwards the AP group name to the SaMOG Gateway in the Access-Request message during initial attach, re-authentication, or handover. The SaMOG Gateway parses the AP group name and forwards it to:

• STa Diameter AAA server in the ANID AVP over DER/AAR messages

• RADIUS AAA server in the Called-Station-Id AVP over the Access-Request message

• External, co-located, or Local P-GW (LBO) in the TWAN-Identifier IE in the SSID sub-field over the Create Session Request message.

  Important:

  If the maximum length of the AP group name exceeds 32 octets, the SaMOG Gateway will not include the AP group name in the SSID field of the TWAN-Identifier IE.

The AAA server and P-GW can use the AP group name information to select Gx policies for the P-GW session. Different Gx policies can be chosen for different AP groups based on the AAA/PCRF configuration.

The AP group name information can be included with or without the "grp" prefix. When the AP Group name is included with the “grp” prefix, it can be present anywhere in the Called-Station-Id AVP. When the AP Group name is included without the "grp" prefix, it must be the last token preceded by the SSID token in the “Called-Station-Id” attribute.

The SaMOG Gateway currently supports the following AP group name formats in the Called-Station-ID AVP:

• mac<MAC>:grp<AP-Group-Name>

• grp<AP-Group-Name>:<SSID>

• cgi<CGI>:grp<AP-Group-Name>

• cgi<CGI>:mac<MAC>:grp<AP-Group-Name>

• <MAC>:<SSID>:<AP-Group-Name>

The SaMOG Gateway complies with 3GPP Release 11 SaMOG specifications for the STa interface as defined in TS 29.273 V11.4. The STa interface is defined between a non-3GPP access network and a 3GPP AAA server/proxy. The SaMOG Gateway uses the STa interface to authenticate and authorize the WLAN UEs. The SaMOG Gateway can communicate with the AAA Server/proxy over the IPv4 or IPv6 interface.

The SaMOG Gateway's MRME service supports the selection of a 3GPP AAA proxy based on the IMSI via the operator policy feature.

The operator policy provides mechanisms to fine tune the behavior of subsets of subscribers above and beyond the behaviors described in the user profile. It also can be used to control the behavior of visiting subscribers in roaming scenarios, enforcing roaming agreements and providing a measure of local protection against foreign subscribers.

An operator policy associates APNs, APN profiles, an APN remap table, and a call-control profile to ranges of IMSIs. These profiles and tables are created and defined within their own configuration modes to generate sets of rules and instructions that can be reused and assigned to multiple policies. In this manner, an operator policy manages the application of rules governing the services, facilities, and privileges available to subscribers. These policies can override standard behaviors and provide mechanisms for an operator to get around the limitations of other infrastructure elements, such as DNS servers and HSSs.

The operator policy configuration to be applied to a subscriber is selected on the basis of the selection criteria in the subscriber mapping at attach time. A maximum of 1,024 operator policies can be configured. If a UE was associated with a specific operator policy and that policy is deleted, the next time the UE attempts to access the policy, it will attempt to find another policy with which to be associated.

A default operator policy can be configured and applied to all subscribers that do not match any of the per-PLMN or IMSI range policies.

Changes to the operator policy take effect when the subscriber re-attaches and subsequent EPS Bearer activations.

The P-GW selection function enables the SaMOG Gateway's MRME service to allocate a P-GW to provide PDN connectivity to the WLAN UEs in the trusted non-3GPP IP access network. The P-GW selection function can employ either static or dynamic selection.

The SaMOG Gateway uses the Gn' reference point between the SaMOG and GGSN. The SaMOG (acting like an SGSN) initiates the creation of PDP context a GTP tunnel with the GGSN for each UE. The SGTP is compliant to Release 7 for GTPv1 specification 29.060. The GGSN selection is based on the DNS query.

The GGSN node is selected as per the 3GPP standard for resolving the IP address using DNS query. The DNS query contains the dns-apn string in the form of <apn-name>.mncXXX.mccYYY.gprs, and the apn-name is obtained from AAA-Server during Access-Accept message. The MCC and MNC values are derived in the following priority:

When SaMOG interacts with pre-release 7 network elements (RADIUS based interfaces) it uses A/AAA queries. When SaMOG interacts with post-release 7 network elements (Diameter based interfaces) it uses the NAPTR queries.

The SaMOG Gateway's MRME service proxies RADIUS accounting messages to a RADIUS accounting server and selects the server based on an IMSI range. Upon receiving an Accounting Stop message, the MRME service clears the subscriber session.

The SaMOG Gateway's MRME service terminates RADIUS authentication requests. IEEE 802.1X authenticators will function as RADIUS clients and generate Access Request messages to authenticate and authorize the WLAN UEs.

The SaMOG Gateway's MRME service generates RADIUS disconnect messages that are sent to the WLCs over IPv4 or IPv6 transport for network or AAA initiated detach and admin disconnections. For a network initiated detach, the SaMOG Gateway's MRME service sends a RADIUS disconnect message to the WLC as per RFC 3576, which is the RADIUS client. Disconnect Message transactions between the WLC and SaMOG are authenticated using a shared secret mechanism. Statistics for these RADIUS disconnect messages can be retrieved via. bulk statistics or the output of CLI show commands.

The SaMOG Gateway's MRME service uses an STa interface re-authorization procedure between the 3GPP AAA server and the trusted non-3GPP access network to enable the 3GPP AAA server to modify previously-provided authorization parameters, which may occur due to a modification of a subscriber profile in the HSS.

Transactions between the RADIUS client and the RADIUS server are authenticated through the use of a shared secret. To authenticate Access Request messages containing the EAP-Message attribute, the SaMOG Gateway's MRME service uses the Message-Authenticator as defined in RFC 3579. The Message-Authenticator is an HMAC-MD5 hash of the entire Access-Request packet, including Type, ID, Length and Authenticator attributes, using the shared secret as the key, as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, and Request Authenticator attributes).

SaMOG supports the RADIUS attribute "NAS-Identifier" in the RADIUS Authentication and Accounting messages, as defined by RFC 2865. The Access point/WLC can include the NAS-Identifier AVP either in the Authentication or Accounting messages (Start/Interim). SaMOG supports NAS-Identifier value as a 64-byte string value and validates string formats only. SaMOG includes the "NAS-Identifier" attribute in the Disconnect Message towards the WLC/Access point (if received from WLC) during UE (DHCP-release) initiated detach and network initiated disconnect procedures or admin clear.

With StarOS Release 18 and later, the Trusted WLAN AAA Proxy (TWAP) sends the Layer 2 attach trigger to the Trusted WLAN Access Gateway (TWAG) (with the MAC address and subscription data of the UE) after a successful EAP authentication. The SaMOG Gateway waits until a tunnel is established for S2a/Gn procedures before forwarding the EAP Success message to the UE.

For an EoGRE access-type, the IP address of the UE is communicated using tunneled DHCP procedure.

For L3IP access-type, the IP address of the UE is communicated using out-of-band DHCP.

For call flow information, refer SaMOG Gateway Session Establishment (StarOS Release 18 and later) for PMIPv6 access-type, and SaMOG Gateway EoGRE Session Establishment (StarOS Release 18 and later) for EoGRE access-type.

The figure below shows an SaMOG Gateway session establishment flow using the EoGRE access type in StarOS Release 18 and later. The table that follows the figure describes each step in the flow.

Figure 13. SaMOG Gateway EoGRE Session Establishment

The figure below shows the message flow to delegate an IPv6 prefix to the user equipment (UE) using SLAAC for EoGRE access type. The table that follows the figure describes each step in the message flow.

Figure 14. SaMOG Gateway IPv6 prefix Over EoGRE Using SLAAC

The table below describes the steps in the message flow for dual-stack support using SLAAC over EoGRE.

The SaMOG web-based authorization and session establishment for a non-EAP or non-UICC device occurs in two phases:

Using web authorization, a subscriber can connect multiple non-EAP devices and one EAP based device using the same IMSI-based subscription at the same time. All PDN connections of a subscriber have different bearer IDs. The connections are routed to the same P-GW or GGSN in order to apply the APN level QoS on all the PDN connections. The SaMOG Gateway performs P-GW, GGSN, or L-GW selection for the first PDN connection for the subscriber, and all subsequent connections are routed to the same P-GW, GGSN, or L-GW.

When pre-authentication completes and on successful authentication of the UE through the external web portal, SaMOG disconnects the UE from the WiFi. The UE then automatically reconnects to WiFi, and SaMOG obtains a new IP address for the UE using a GTP tunnel towards P-GW (TAL phase). The UE is then expected to send a DHCP Request/Discover message to learn the new IP address (as WiFi was disconnected and reconnected).

The DHCP lease time for the IP address assigned during the pre-authentication and TAL phases can be configured using the dhcp lease command under the APN Profile Configuration Mode.

The SaMOG gateway can recover AAA manager and Session manager failures for both pre-authentication phase and TAL phase as long as the sessions are fully connected. SaMOG maintains the MAC to IMSI mapping and MAC to Session manager mapping with the IPSG manager to ensure that the PDN connections of the subscriber is connected to the same Session manager.

This section identifies limitations, restrictions, and dependencies for the SaMOG Web Authorization feature: