Service Awareness Flexi ISN

FISNFI50EMED.03

Nokia Siemens Networks Flexi ISN, Rel.

5.0,

Operating Documentation, v. 4

Service Awareness in Nokia Siemens Networks Flexi ISNDN04134609

Issue 7-3 en

2 DN04134609Issue 7-3 en

Service Awareness in Nokia Siemens Networks FlexiISN

Id:0900d805808c041b

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2011. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

DN04134609Issue 7-3 en

3

Service Awareness in Nokia Siemens Networks Flexi ISN

Id:0900d805808c041b

Table of ContentsThis document has 90 pages.

1 Changes in service awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Changes in release 5.0 CD4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Changes in release 5.0 CD3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Changes in release 5.0 CD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Changes between releases 4.0 and 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Changes between releases 3.2 and 4.0 . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Overview of the service awareness functionality . . . . . . . . . . . . . . . . . . 122.1 Introduction to service awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 User profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.3 Flow profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.4 Charging profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.5 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.6 L4 flow specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.7 L7 flow specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.8 Charging class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.9 L4 service component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.10 L7 service component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.11 Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3 Service awareness in 3GPP reference architecture . . . . . . . . . . . . . . . 282.4 Service awareness in the Flexi ISN architecture . . . . . . . . . . . . . . . . . . 292.4.1 Layered control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.2 Service awareness architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5 Charging architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.6 External control elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.1 Offline charging element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.2 Online charging element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.3 User profile retrieval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.6.4 Provisioning service profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.6.5 Interworking with IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.6.6 Push proxy gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7 Service engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7.1 L4 analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7.2 L7 analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.7.3 Proxy L7 analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.7.4 Basic versus proxy analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.7.5 P2P analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Service switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1 Standard access point model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.2 Single access point model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3 Access point aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4 Context-prohibited access points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 DN04134609Issue 7-3 en


Id:0900d805808c041b

3.5 Access point roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.6 Transparent service authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7 IP address management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.8 Packet forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.9 DNS redirection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Service control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1 Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2 Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4 Access awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.5 Location awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.6 Roaming awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.7 Treatment Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 Service bandwidth limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 Differentiated charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1 Basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Online charging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 Offline charging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 Metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.1 Volume-based metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.4.1.1 Volume metering with L3/4 analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4.1.2 Volume metering with basic L7 analysis . . . . . . . . . . . . . . . . . . . . . . . . . 585.4.1.3 Volume metering with L7 proxy analysis. . . . . . . . . . . . . . . . . . . . . . . . . 605.4.2 Hit-based metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.4.3 Time-based metering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.5 Time step charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.6 MIME-based charging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.7 MMS message charging according to the sender. . . . . . . . . . . . . . . . . . 665.8 Bearer charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.9 Special charging models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.9.1 Mixing offline and online charging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.9.2 Event charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.9.3 Revenue sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.9.4 Zero rating. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.10 Charging concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.10.1 Default quota. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.10.2 Quota consumption timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.10.3 Quota holding timer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.10.4 Non-permission timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.10.5 Tariffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.10.6 Wallets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.1 WAP 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2 HTTP and WAP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.3 Basic HTTP and WAP analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3.1 Malformed HTTP traffic handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75


5


Id:0900d805808c041b

6.4 Proxy HTTP and WAP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.5 i-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.5.1 Basic i-mode analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.5.2 Proxy i-mode analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.6 Redirection of browsing traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.6.1 Basic WAP 1.x redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.6.2 Proxy HTTP redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.6.3 Configured redirection for WAP and HTTP traffic . . . . . . . . . . . . . . . . . 77

7 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.1 MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.2 Basic MMS analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.3 Proxy MMS analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807.4 MMS message charging according to the recipients of the message . . 817.5 SMTP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.1 Overview of RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.2 Basic RTSP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.3 Proxy RTSP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.4 Redirection of streaming traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9 PoC analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10 FTP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

11 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6 DN04134609Issue 7-3 en


Id:0900d805808c041b

List of FiguresFigure 1 L4 and L7 flow specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 2 Relations between the L4 flow specification, flow, and service components

23Figure 3 Relationships between service components and flows. . . . . . . . . . . . . . 25Figure 4 Flows and flow specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 5 Service control layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figure 6 External control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 7 External control with separate Gx interface . . . . . . . . . . . . . . . . . . . . . . 30Figure 8 Service awareness architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figure 9 Charging architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figure 10 Access point in Flexi ISN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figure 11 Flexi ISN single access point for all services . . . . . . . . . . . . . . . . . . . . . 43Figure 12 Multiple access points in Flexi ISN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 13 Service switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 14 DNS redirection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 15 Effect of QCT expiration in Flexi ISN . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 16 Effect of interrupting a PDP context update on time-based metering . . . 63Figure 17 Wallets and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 18 WAP interaction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 19 HTTP interaction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 20 Multimedia transfer session with the RTP transferring the data stream . 82


7


Id:0900d805808c041b

List of TablesTable 1 Charging profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Table 2 3GPP and Flexi ISN terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Table 3 Supported analysis modes for L7 protocols . . . . . . . . . . . . . . . . . . . . . 38

8 DN04134609Issue 7-3 en


Id:0900d805808c041b


9


Changes in service awareness

Id:0900d805808c042d

1 Changes in service awareness

1.1 Changes in release 5.0 CD4Changes in contentA new parameter has been added for HTTP/WAP1.x user identity header enrichment:

• The Header Name to Add IMEISV

Changes in documentationSection Proxy HTTP and WAP analysis has been updated with header enrichment IMEISV information.

Section Volume-based metering has been updated with a note.

1.2 Changes in release 5.0 CD3Changes in contentMalformed HTTP traffic handling is provided.

Changes in documentationSection Malformed HTTP traffic handling has been added.

Section Basic RTSP analysis has been updated.

1.3 Changes in release 5.0 CD2Changes in contentENUM DNS interface has been removed.

Changes in documentationThe following sections have been removed:

• ENUM DNS • Use of ENUM/DNS queries for rewriting HTTP and MMS server URLs

1.4 Changes between releases 4.0 and 5.0Changes in contentThe separate Gx (Diameter Policy Control) interface is supported.

The ISC/ISD interface is no longer supported.

The Real-Time Video Sharing (RTVS) feature is no longer maintained.

The basic HTTP analyzer can also be used for prepaid automatic redirection.

In Section Volume metering with basic L7 analysis the L7 volume metering disabled option has now been included.

New information about P2P licenses has been added in Section P2P analysis.

New parameters have been added for the extended HTTP/WAP1.x user identity header enrichment:

10 DN04134609Issue 7-3 en


Id:0900d805808c042d


• The subscriber’s zone ID • The subscriber’s profile ID • The Diameter session error flag • The subscriber’s billing type

The Go interface is no longer supported.

Changes in documentationThe following sections have been updated with information about the separate Gx inter-face:

• Layered control • Interworking with IMS • Access point roles • Treatment Classes

Section Proxy HTTP redirection has been updated with a Note.

Sections L4 flow specification and Treatment Classes have been updated.

Basic HTTP analyzer information has been updated in the following sections:

• Configured redirection for WAP and HTTP traffic • Basic HTTP and WAP analysis • Redirection

Values in table Charging profiles in Section Charging profile have been updated.

The Section Treatment Classes has been updated with new title (previously known as Service-based QoS).

Header enrichment information has been updated in the following sections:

• Proxy HTTP and WAP analysis

1.5 Changes between releases 3.2 and 4.0Changes in contentThe HTTP proxy analyser is able to redirect traffic (browsing and MMS) and rewrite the URI according to the new redirection parameters in the L7 flow configuration (Redirect Address, Redirect Port, HTTP Host Header Rewrite, HTTP Request Format, URI Rewrite).

Traffic redirection is also supported in L4 analysis (defined with the Redirect Address and Redirect Port parameters in the L4 flow configuration).

Changes in documentationIn Section MMS message charging according to the sender, a note has been added, mentioning that this feature is only applicable for uncompressed MMS messages.

In Section Basic MMS analysis, information has been added about compressed MMS charging when using L7 content volume charging class.

New section added: Service bandwidth limit.

In Section Basic MMS analysis, information has been clarified that for MMS analysis, only uplink hit triggers are used (not uplink and downlink hit triggers).

New section added: Proxy HTTP redirection.


11



Id:0900d805808c042d

Redirection information has been updated in the following sections:

• L4 service component • L7 service component • ENUM DNS • L4 analysis • Basic versus proxy analysis • Redirection • Configured redirection for WAP and HTTP traffic • Usage of ENUM/DNS queries for rewriting HTTP and MMS server URLs • Basic MMS analysis • Proxy MMS analysis

In Section SMTP analysis, information clarified that SMTP L7 analysis is used for ana-lyzing SMTP requests and responses for hit-based charging. L4 analysis should be used if no hit-based charging is required.

12 DN04134609Issue 7-3 en


Id:0900d805808d42a5

Overview of the service awareness functionality

2 Overview of the service awareness function-ality

2.1 Introduction to service awarenessOne of the major features of Flexi ISN is the service awareness (SA) functionality. This functionality is implemented as an optional feature on top of the GGSN functionality defined in 3GPP standards. It provides the mobile operators with new capabilities that make it easier to deploy, control and charge mobile services. The SA functionality makes it possible to reduce the number of access points in the network and to offer IP flow charging for post-paid and prepaid subscribers. The SA functionality is also sup-ported for other access networks.

A basic GGSN simply forwards user plane traffic between access networks connected via the Gn/Gp interface and data networks connected via the Gi interface. A GGSN mainly provides a bit pipe where traffic is blindly passed. Access points are used in this model for differentiation based on service categories and traffic for one PDP context is treated in a similar way.

Service awareness removes this restricted approach by introducing traffic analysis. Flexi ISN is able to categorize traffic inside one PDP context based on the analysis per-formed in different layers:

• Layer 3 (network layer) analysis categorizes the traffic based on the IP header infor-mation, which includes the destination address and protocol number.

• Layer 4 (transport layer) analysis categorizes the traffic based on the layer 3 infor-mation and the port number in the TCP and UDP headers.

• Layer 7 (application layer) analysis categorizes the traffic based on the L7 protocol headers. Only selected L7 protocols such as WAP, HTTP and the multimedia mes-saging service (MMS) are supported. The analysis is in this case L7-specific and categorization is done based on, for example, the URL.

Classification of the traffic in the analyzers is done based on the service profile, which also defines the action for categorized traffic flows. The classification is defined by flow specifications and the service component defines the action:

• differentiated chargingThe Flexi ISN supports metering of traffic according to volume, time, or events. The service profile defines how traffic is metered and what rating group identifier is used in the charging interfaces.

• gatingThe service profile defines whether traffic is allowed to pass and if there are no rules covering the traffic, it is dropped.

• QoS controlThe Flexi ISN is able to modify the QoS based on the active traffic flows.

• service switching and network address translation (NAT)The Flexi ISN forwards the traffic to the correct Gi connection based on the catego-rization. NAT may be applied, if necessary.

• redirectionThe Flexi ISN is able to redirect WAP, HTTP and RTSP traffic flows.

The actions are defined by service components in the service profile. When the traffic has been categorized based on the traffic analysis, the selected action is not always the


13



Id:0900d805808d42a5

same, because multiple service components can be linked to the same flow specifica-tion. A service is used to link service components and flow specifications. Access, location and roaming awareness makes it possible to restrict the usage of a certain service to a certain access technology (for example, 3G networks), location (for example, certain roaming partners), or roaming case. The user profile provides sub-scriber-specific service control by defining the services allowed to a certain subscriber. The default user profile is defined in the access point configuration, but it is possible to get the user profile from an external control element. In summary, the selected action for a certain traffic flow can differ based on the access technology, location, roaming status, and subscriber.

The main purpose of service awareness is to enable policy-based charging and packet forwarding. Service awareness also enables the single access point name (APN) solu-tion, see Section Single access point model. The functionality can also be used for security reasons. For example, a policy decision may dictate that a certain traffic type is not allowed at all and the gating configuration will block all unwanted traffic in the Flexi ISN. For more information about security, see Security in Nokia Siemens Networks Flexi ISN.

Service awareness is supported only in IPv4.

2.2 ConceptsThis section explains the main concepts related to service awareness.

2.2.1 Service profileThe service profile is the configuration that is used for traffic classification: differentiated charging and service switching. It can be locally configured and consists of the following configuration objects:

• services • flow specifications • charging classes

There is one service profile defined for each Flexi ISN.

2.2.2 User profileThe service profile defines all the rules for service awareness. However, only some of those rules apply to individual PDP sessions. For example, some rules may require a subscription so they are not automatically enabled for all subscribers. Some rules might be allowed only in a certain access point. The user profile defines this personalization. It defines which rules apply to certain PDP sessions.

The user profile contains the following information:

• a list of active services: Instead of defining each individual rule from the service profile in the user profile, only the services are defined in the user profile. Service is the key concept in the Flexi ISN, because it is linked to individual flow specifications through the service components. This linkage is explained in Sections L4 service component and Service awareness in the Flexi ISN architecture.

• primary service: The meaning of the primary service and the primary access point is explained in Section Single access point model.

DINHNHAT

Highlight

14 DN04134609Issue 7-3 en


Id:0900d805808d42a5


• the user authentication parameters: The Flexi ISN activates the access points according to the listed services. If the access point activation requires authentication parameters, they can be taken from the user profile.

• charging profile • wallet information, if wallet-specific charging is used • primary and secondary Online Charging System (OCS) for online charging • default treatment class (TREC)

If detailed personalization is required, the user profiles must be stored in an external reg-istry, because the Flexi ISN does not maintain information about inactive subscribers. When a PDP context is activated, the Flexi ISN can then fetch the user profile using either the LDAP, RADIUS, or Gx interface. Also, the user profile can be dynamically updated using the RADIUS, or Gx interface over the duration of a PDP session.

The Flexi ISN enables a cost-efficient implementation for storing user profiles in external registries because it is not necessary to store all possible information for all subscribers. If some information is missing from a user profile, or the user profile is completely missing from the registry, the Flexi ISN will use locally configured default values. These default values are part of the access point configuration so it is possible to define access-point-specific default values for user profiles.

2.2.3 Flow profileThere is one flow profile for each PDP session in the Flexi ISN. The flow profile consists of all the dynamic flows created, based on the active traffic analysis. The flow concept is defined in Section Flow. Traffic analysis monitors active traffic flows and creates new flows to the flow profile. Then, the control function defines the action to be executed for the flow:

• The service control makes the packet forwarding decision. The flow may be blocked completely. It may sometimes be redirected, but in most cases packets are simply forwarded to the Gi connection selected by the service control.

• Credit control is applied if online charging is enabled. Packets cannot be forwarded unless there is a quota. The credit control defines the quota.

• The QoS policy control makes the QoS decisions for the flow.

If traffic is allowed to pass, traffic analysis will meter the volume, time and hits related to the flow.

2.2.4 Charging profileThe charging profile defines how the mobile subscriber is charged. There are two main alternatives: offline and online charging. Offline charging is based on charging data records (CDR), which are transmitted to the charging system over the Ga interface. As an alternative, the Flexi ISN is able to produce also CDR files which can be fetched from the Flexi ISN with the File Transfer Protocol (FTP). Online charging uses the Gy inter-face, which is based on the Diameter Credit Control Application (DCCA). For backward compatibility, it is also possible to use Nokia Siemens Networks proprietary RADIUS online charging.

The charging profile can be determined with the following methods:


15



Id:0900d805808d42a5

• charging characteristicsWhen the SGSN sends a request for creating the PDP context, the request might contain an information element called Charging Characteristics. This value has been fetched from the HLR. This method is used if the charging profile has the value HLR in the user profile, or the access point. If the network access server (NAS) inter-face is used to create the PDP context 3GPP-Charging-Characteristics can be used in the RADIUS message to indicate the requested charging profile.

• user profileThe charging profile can be listed in the user profile which is fetched from the RADIUS server, or the Nokia Siemens Networks Profile Server (NPS).

• access pointThe charging profile can be defined in the access point configuration. This method is used if the user profile is not fetched from the external network element.

Table 1 defines which charging profile types are supported in the different selection methods:

If none of the selection methods provides the charging profile, the default charging profile is always post-paid.

The charging profile value has the following semantics in the Flexi ISN:

• post-paidThe offline charging interface is used. The mobile subscriber is billed after the service use.

• prepaidThere are two prepaid alternatives depending on whether online charging is enabled. In the pure online prepaid case the online charging interface is used. The mobile subscriber has paid in advance for the use of the services. The offline charging interface may still be used in online prepaid charging, for example, for sta-tistics, but the actual charging is performed through the online interface. However, if the online charging interface is disabled, it is still possible to enable offline prepaid charging.

Charging profile Charging char-acteristics

User profile Access point

Post-paid Yes Yes Yes

Prepaid Yes Yes Yes

HLR - Yes Yes

Hot billing Yes Yes Yes

Flat rate Yes No No

Post-paid with credit control

No Yes Yes

Prepaid with credit card

No Yes No

Wallets No Yes No

Table 1 Charging profiles

16 DN04134609Issue 7-3 en


Id:0900d805808d42a5


• HLRThe HLR alternative is supported when the charging profile is defined in the user profile, or access point configuration. In this case, the actual charging profile is defined in the charging characteristics.

• hot billingOffline charging is used. Depending on the Flexi ISN configuration there are three alternatives: special hot billing charging data records (CDRs) are generated, normal CDRs are generated, or no CDRs are generated at all. Hot billing means that the CDRs generated for a call are sent to the billing centre at once.

• flat rateBy default, there is no charging at all. However, if the flat rate functionality is disabled in the Flexi ISN, the Flexi ISN uses offline charging and produces normal CDRs. Flat rate means that the mobile subscriber pays a fixed fee (for example, a monthly payment) for the use of the services. This fee covers all the use.

• post-paid with credit controlThe offline charging interface is used for the actual charging, but the online charging interface is used to control the service usage. In other words, both the offline and online charging interfaces are used. The mobile subscriber is billed after the service use, but there might still be some restrictions on the service use, which are con-trolled through the online charging interface. If the online charging system (OCS) does not grant a quota for a service, the mobile subscriber cannot access it.

• prepaid with credit cardThis charging profile value is only used in online charging. The mobile subscriber is handled as a prepaid user. If there is some failure in the online charging, the operator can take into account the fact that the mobile subscriber can also be billed afterwards. For generic prepaid mobile subscribers, billing might not be possible after service use because the mobile subscriber might be anonymous.

• walletsIf wallet-specific charging is enabled, the Flexi ISN can use multiple wallets for charging. Each service is then linked to a wallet and each wallet might have a differ-ent charging profile. For more detailed information, see Section Wallets.

2.2.5 ServiceA service is the key concept in service awareness. It is the glue that links all the other concepts together. It is also the entity that might be visible to the mobile subscriber (the actual visibility depends on the operator deployment model). The mobile subscriber can subscribe to the services, or the service can be activated automatically for the mobile subscriber.

Service is used to control the personalization. The services, which are to be activated for the mobile subscriber, are listed in the user profile. These services are then linked to the service components and the individual flow specifications. That way one service will define which rules from the service profile are currently active in one PDP session. Addi-tional service control is applied locally in the Flexi ISN through access, location and roaming awareness: services listed in the user profile might be disabled temporarily during the PDP session based on the current access technology, location, and roaming status of the PDP session.

When the Flexi ISN requests a quota for traffic flows, or when the Flexi ISN reports the use to the charging system, a service identifier, or a rating group identifier, or both, are


17



Id:0900d805808d42a5

used to separate different traffic flows. This enables active monitoring of which services are actually being used in the network.

Service configuration consists of the following parameters:

• service identifierThis is a numeric identifier for the service.

• service nameThis is a textual identifier for the service.

• access point linked to the serviceThis information is used to define service switching (packet forwarding).

• charging priorityThis is used in situations where multiple services are linked to the same entity. In those situations the service with highest priority is selected.

• access awareness configurationThis defines the access technologies (2G, 3G, or WLAN) where the service is allowed.

• location awareness configurationThis defines the locations where the service is allowed.

• roaming awareness configurationThis defines whether the service is allowed in different roaming cases.

• optional notification to be sent when a service is used for the first time during the PDP session

• service-specific bandwidth management configurationFor more information, see Section Service Bandwidth Limit in Quality of Service in Nokia Siemens Networks Flexi ISN.

2.2.6 L4 flow specificationThe flow specification is the main configuration object used for traffic classification. There are two types of flow specifications: transport layer (L4) and application layer (L7) flow specifications.

The L4 flow specification includes the following attributes:

• uplink IP address, or subnet • uplink port number, or port range • TREC ID. This defines the QoS parameters used for L4 flow traffic • IP protocol identifier. The list of protocol identifiers is maintained by IANA

(http://www.iana.org/assignments/protocol-numbers). For example, 6 and 17 are used for TCP and UDP, respectively.

• L7 analysis (see further below) to be performed with flow specification • additional header name

The use of an additional header name enables the networking of Java applications in incompatible user equipment (UE). To be able to differentiate this traffic the addi-tional header field has to be analyzed from the HTTP traffic to the WAP access point and it has to be used for L7 flow matching.This attribute indicates the header name to be analyzed.The requested header value indicates the WAP-GW address and also other speci-fiers that must be considered in L7 analysis. One header name can include several values to be checked. The values for the additional header name are configured in L7 flow specification.

18 DN04134609Issue 7-3 en


Id:0900d805808d42a5


L4 flow specification is used to categorize traffic according to L3, or L4 network layer flows.

When the user plane traffic is analyzed, the Flexi ISN tries to find the best match based on the above attributes if no existing flow has yet been found. Wild card values can be used in all the above mentioned attributes. The best match is defined based on the fol-lowing rules:

1. The algorithm starts with a set of all the flow specifications. This set is refined itera-tively by dropping the flow specifications which do not match with the packet. As a first step, if none of the services linked to the flow specification are active in the related PDP context, the flow specification cannot match with the packet. These flow specifications will be dropped first.

2. If the packet is a TCP, or UDP packet, the Flexi ISN first tries to find the best match from the flow specifications where the configured IP protocol identifier is TCP or UDP, respectively. If the packet is not a TCP or UDP packet, the best match algo-rithm proceeds directly to step 6.

3. The next step is to check the configured port number of the flow specification. Only the flow specifications where the port matches with the configured port number are used in the next step. If there are no flow specifications after this step, the best match algorithm proceeds directly to step 6.

4. The best match is determined based on the IP address with the remaining flow spec-ifications. The best match based on the IP address is defined by the configured uplink IP address in the flow specification. If the packet matches with two flow spec-ifications, the flow specification with the more accurate subnet definition is selected. The least accurate match is in the flow specifications which cover all the IP addresses, while the most accurate match is defined in the flow specifications which match with only a single IP address. If there is only one flow specification after this step, this flow specification has the best match. If there are no matching flow speci-fications, the best match algorithm proceeds to step 6. If there is still more than one flow specification, the algorithm proceeds to step 5.

5. With the remaining flow specifications, the algorithm will select the best match based on the configured port number. The best match based on port numbers is defined by the configured uplink port number, or range. If the port number matches with two flow specifications, the flow specification covering fewer ports with the configured port range has the best match. Only one flow specification will be selected after this step and that flow specification will have the best match.

6. The algorithm proceeds to this step if the packet is not a TCP or UDP packet, or the TCP and UDP specific part of the algorithm cannot find any matching flow specifica-tion. In this step the algorithm drops the flow specifications which do not have a matching IP address. If there are no flow specifications after this step, there is no matching flow specification and the packet is dropped.

7. In this step the algorithm checks if there are any flow specifications which match with the configured IP protocol identifier and no wild card value is used in the configura-tion. If no such flow specifications exist, the algorithm will continue with the flow specifications where a wild card has been configured as the IP protocol identifier. If no flow specifications match, the packet is dropped.

8. With the remaining flow specifications, the best match is determined based on the IP address. This step is similar to step 4.

g In case of a wildcard port configuration, for example when “Start Port Number” and “End Port Number” are 0, the algorithm will not follow the flow of execution as described in


19



Id:0900d805808d42a5

the above rules. Instead, all flows that contain non-wildcard ports will be checked first and if no flow match is found, then the algorithm checks the remaining wildcard flow specifications.

The above algorithm describes a high-level view of how the best match is defined. It is not the actual algorithm used in the Flexi ISN product. The actual algorithm produces the same result as the above algorithm, but uses complex data structures and proce-dures for efficiency reasons.

ExampleIn this example there are the following specifications:

• Flow specification A matches with all TCP packets that have the port number 80. Service Y is linked to A.

• Flow specification B matches with all traffic. Service X and service Y are linked to B. • Flow specification C matches with all TCP packets going to 10.2.3.14. The port is

undefined. For example, “Start Port Number = 0”, “End Port Number = 65535” • Flow specification D matches with all traffic going to 10.2.3.14. Service Y is linked to

D. • Flow specification E matches with all TCP packets going to port numbers 1-1024.

Service Y is linked to E.

For the following IP packets, the best match can be then defined:

• Only service X is active. A TCP packet to 10.2.3.14, port number 80, will then match with flow specification B, because it is the only flow specification where X is allowed.

• Service Y is active. A TCP packet to 10.2.3.14, port number 80, will then match with flow specification C. Flow specifications A, B, C, D, and E match. Flow specifications A, C, and E are have better match than B and D, because the IP protocol is defined in the flow specifications. C is selected because it has most accurately defined IP address.

• Service Y is active. A UDP packet to 10.2.3.14, port number 80, will then match with flow specification D. Only B and D match with UDP traffic and D has a better match with respect to the IP address.

• Service Y is active. A TCP packet to 10.2.3.15, port number 80, will then match with flow specification A. Flow specifications A, B and E match. A and E have better match than B, because in B the IP protocol identifier uses a wild card. A and E both use the same accuracy for the IP address so the selection between A and E is based on the port number. A is selected because the port number is more accurately defined.

• Service Y is active. A TCP packet to 10.2.3.15, port number 81, will then match with flow specification E. Flow specifications B and E match, and E is selected because the IP protocol is explicitly defined.

• Only service Z is active. In this case, all the packets would be dropped, because no matching flow specification can be found.

It is possible to configure the IP address also as a domain name. In this case, the Flexi ISN will analyze DNS requests from terminals. If the DNS request contains one of the configured domain names, the Flexi ISN will dynamically create an L4 flow specification in its memory where the domain name has been replaced with the resolved IP address. The best match is then defined based on the dynamically created L4 flow specifications.

20 DN04134609Issue 7-3 en


Id:0900d805808d42a5


The treatment class (TREC) ID in the L4 flow specifications defines which QoS is applied for the services and their related traffic flows. The TREC is a combination of the most relevant 3GPP QoS parameters. For more information about TREC and service-based QoS, see Section Service switching.

The L7 analysis attribute defines whether and which L7 analysis must be performed for the matching L4 traffic. The following L7 analyses are supported:

• HTTP: basic L7 analysis for either normal HTTP or WAP 2.0, including special analysis for MMS over HTTP or WAP 2.0.

• WAP: basic L7 analysis for WAP 1.x, including special analysis for MMS over WAP 1.x.

• DNS: basic L7 analysis used for DNS redirection. • RTSP: basic L7 analysis for Real-Time Steaming Protocol (RTSP), including the L7

analysis for the dynamically created flows of the Real-Time Transport Protocol (RTP).

• PoC: L7 analysis for Push to talk Over Cellular (PoC) traffic is enabled. • Proxy SMTP: proxy L7 analysis for Simple Mail Transfer Protocol (SMTP) traffic,

including MIME-type detection. • Proxy FTP: proxy L7 analysis for File Transfer Protocol (FTP) traffic. • Proxy HTTP: proxy L7 analysis for HTTP or WAP 2.0, including special analysis for

MMS over HTTP or WAP 2.0, MIME-type detection and i-mode analysis. • Proxy WAP: proxy L7 analysis for WAP 1.x, including special analysis for MMS over

WAP 1.x and MIME-type detection. • Proxy RTSP: proxy L7 analysis for RTSP, including L7 analysis for the dynamically

created flows of the RTP. • P2P analysis • SIP

The difference between basic and proxy analysis is defined in Section Basic versus proxy analysis. For more information about P2P analysis, see P2P Traffic Management in Nokia Siemens Networks Flexi ISN.

Figure 1 illustrates the relationship between the L4 and L7 flow specifications. The first L4 flow specification is not linked to any L7 flow specification, so only the L4 analysis is performed. The second L4 flow specification is linked to three different L7 flow specifi-cations, while the last L4 flow specification is linked to only one. One L7 flow specifica-tion can only be linked to one L4 flow specification.

Figure 1 L4 and L7 flow specifications

For information about how services are linked to the L4 flow specifications, see Section L4 service component.


21



Id:0900d805808d42a5

2.2.7 L7 flow specificationThe L7 flow specification is a configuration object that defines how the L7 analysis is per-formed. The L7 flow specification is always linked to exactly one L4 flow specification, which defines which traffic is under the L7 analysis configured by the L7 specification.

The following attributes are used to define matching rules for the L7 analysis:

• match orderFor the L7 analysis, the best match cannot be determined without an explicit priority attribute. L7 analysis will iterate L7 flow specification in the order defined by the match order, and the first matching L7 flow specification will have the best match.

• Uniform Resource Identifier (URI)This attribute defines the URI for L7 traffic. There is limited support for regular expressions, because full support for regular expressions would consume a lot of processing power in the L7 analysis. One, or more wild cards can be used in the URI. The use of URI configuration depends on the analyzed L7 protocols. In some cases the URI configuration is ignored, because the URI is not a relevant attribute for all possible L7 protocols.

• additional header valuesThis attribute contains one or more header values, which are searched for from the HTTP uplink traffic. The header name is defined in the L4 flow configuration. The values are separated by a comma and wild cards can be used.Since the L7 flow connects to a service, different L7 flows can be created that have different header name/value pairs. These can be linked to different services, or just to one service. This is useful if several headers need to be analyzed.

• uplink hit triggerIf the L7 traffic matches with the uplink hit trigger, the uplink hit is recorded. The value is L7-specific, that is, the semantics of the attribute depend on the L7 used in the analysis. For example, for HTTP traffic, the uplink hit trigger is the HTTP method or methods (for example, GET).

• downlink hit triggerThis attribute is used in a way similar to the uplink hit trigger, but the value is only for the downlink traffic. For example, for HTTP traffic, the downlink trigger is defined as the status code of the HTTP response.

Note that the uplink and downlink hit triggers are used only in basic L7 analysis. Proxy L7 analysis generates a hit based on fixed rules and those analyzers do not differentiate between uplink and downlink hits.

For information about how services are linked to the L7 flow specifications, see Section L7 service component.

2.2.8 Charging classThe charging class defines how traffic is charged.

• rating groupThe charging class defines the rating group identifier to be used in the charging.

• meteringThere are multiple metering types (see below). For each metering type, the metering may be disabled, or enabled. Multiple metering types can be associated with the charging class. In offline charging, the Flexi ISN can always meter everything, for example, for statistical purposes.

22 DN04134609Issue 7-3 en


Id:0900d805808d42a5


• default quotaWhen online charging is used traffic flows are blocked if there is no quota. The default quota is used in situations when the quota has not yet been received from the OCS and there is no reason to believe that the OCS would not grant any quota. The default quota is not used in offline charging.

• quota consumption timer (QCT) (or silence period)The quota consumption timer is used when continuous time metering is enabled. It defines when the Flexi ISN stops counting time in situations where there have not been active traffic flows.

• tariff timesIt is possible to define local tariff change times. If online charging is enabled, the OCS will define the tariff times. So, the configuration applies only to offline charging.

The following metering types are supported:

• plain volume-based metering, which includes all the L3-L7 data (for example, IP headers, TCP headers, actual payload)Uplink and downlink traffic is measured separately.

• content-based meteringThe charging class configuration defines whether protocol headers are included or not. For example, if the charging class controls the metering of the HTTP flow, only the HTTP headers and the HTTP payload are included, or alternatively, only the HTTP payload is included. Uplink and downlink traffic is measured separately. This metering type is used only in basic L7 analysis. Proxy L7 analysis always meters plain volume, also including the L3 volumes.Content volume metering is not supported in P2P analysis.

• hitThe uplink and downlink hits can be measured separately if basic analysis is used. The hits are supported only for L7 flow specifications.Hit-based metering is not supported in P2P analysis.

• timeThe Flexi ISN supports many alternative methods for metering time. See Section Time-based metering for more information.

• time stepWhen the first packet of the service is let go, a predefined time interval ('step') is always charged no matter what the subscriber behavior is during this interval (for example, even if the subscriber cuts the connection). After this interval a new 'step' will be charged when the next packet is let go. See Section Time step charging for more information.

2.2.9 L4 service componentThe L4 service components are used to link the L4 flow specifications to services. The L4 service component consists of the following attributes:

• charging class, which defines how the related L4 flow will be charged and metered • optional secondary charging class, which is used if uplink and downlink flows are

charged according to separate charging classes • L4 flow initiation rule, which defines the packet forwarding action for the flows • service, which is used to select the right service component • redirect address, which defines in which destination address the traffic will be redi-

rected


23



Id:0900d805808d42a5

• redirect port, which defines in which port number the traffic will be redirected

Figure 2 illustrates the relationship between the L4 flow specification, L4 flows and L4 service components. First, there are several L4 flow specifications used to classify the traffic initially. When the best matching L4 flow specification has been found there can be several L4 service components linked to the L4 flow specification. Service is one of the attributes of the service components and the priority of the service defines which service component is used. In the example below, the highest priority service compo-nent is not active for the mobile subscriber so it is ignored during the traffic classification process. Finally, when the matching L4 service component has been found, the L4 flow is created for storing the dynamic status information related to the IP flow. Multiple L4 flows may be active at the same time because the L4 flow specification might use, for example, subnets, while the L4 flows are always tied to a certain IP flow.

Figure 2 Relations between the L4 flow specification, flow, and service components

2.2.10 L7 service componentThe L7 service component serves the same purpose as the L4 service component, but it is linked to the L7 flow specification. The L7 service component consists of the follow-ing attributes:

• charging class, which defines how the L7 flows are charged • optional secondary charging class, which is used if uplink and downlink flows need

to be charged according to different charging classes • optional redirect IP address and port, which are used only in basic WAP 1.x analysis

and proxy HTTP analysis • L7 flow initiation rule, which defines packet forwarding action for the flows • service, which is used to select the right service component • optional flag, which defines whether WAP/HTTP proxy analysis include the user

identity in the additional WAP/HTTP headers before forwarding the analyzed WAP/HTTP request

• URL value, which is sent in charging interfaces if there is traffic matching the service component. The configuration applies only in basic WAP/HTTP analysis.

• optional flag, which defines whether the RTSP URL is passed over the online charging interface. The configuration applies only to basic RTSP analysis.

• optional flag, which indicates if the host header in the HTTP request should be rewritten. It is used only in Proxy HTTP analysis and only if a redirect IP address has also been configured. This flag should be enabled if the traffic is to be redirected to a new MMSC, or a new web server.

24 DN04134609Issue 7-3 en


Id:0900d805808d42a5


• optional flag, which indicates if the format of the HTTP request should be changed from Normal to Proxy and vice versa. It is used only in proxy HTTP analysis and only if a redirect IP address has also been configured. If the traffic has to bypass a proxy, or a WAP gateway and be redirected straight to a web server, or an MMSC, this flag should be set to Normal. If the traffic has to be redirected through a proxy, or a WAP gateway instead of going straight to a web server, or an MMSC, this flag should be set to Proxy. If the format of the HTTP request does not need to be changed, this flag should be disabled.

• optional URI rewrite configuration, which is used by WAP 1.x basic analysis and the HTTP proxy for different use cases. In the case of WAP, the presence of a string in this field indicates that redirection of an MMS to another MMSC is configured and should contain the IP address of the new MMSC in the following format: http://10.85.50.12:8191/.In the case of HTTP proxy, this field has the following different uses: • It indicates a redirection to a new web server, or a new MMSC if an IP address

for a new proxy, or a new WAP gateway has also been configured in the redirect IP address field. In this case the field should contain the hostname, or the IP address of the new web server, or MMSC in one of the following formats: http://www.alpha.com or http://10.85.50.12 or http://10.85.50.12:8191.

• It indicates the previous scenario, but the URL path must also be rewritten. In this case the field should be written in one of the following formats: http://www.alpha.com/new_url_path or http://10.85.50.12/new_url_path or http://10.85.50.12:8191/new_url_path.

• It indicates that only the URL path has to be rewritten. In this case the field should contain the new URL path in the following format: /new_url_path. This case can be used with, or without a configured redirect IP address.

Figure 3 demonstrates the relationships between service components and the flows illustrate how the L7 service components are related to the other concepts. First, the matching L4 flow specification and L4 flow is determined as described in Section L4 service component. Multiple L7 flow specifications can be linked to the L4 flow specifi-cation. For each L7 flow specification multiple L7 service components can be linked to each L7 flow specification. In a way similar to the L4 case, the priority of the service is used to determine the matching service component. The dynamically created L7 flow is then linked to the related dynamic L4 flow. In Figure 3 the leftmost L7 flow specification is linked to a L7 service component that is disabled for the mobile subscriber. In practice it means that the related L7 traffic is blocked in the Flexi ISN.


25



Id:0900d805808d42a5

Figure 3 Relationships between service components and flows

2.2.11 FlowUsing object-oriented terminology, it could be said that flow specification is an abstract class. A pair consisting of a flow specification and linked service components defines one class inherited from the basic flow specification. This class defines both the traffic classification and the action to be performed for the classified traffic. A flow is an object instantiated from these classes. Each flow is specific for a PDP context, or mobile sub-scriber. The terms L4 and L7 flow are used if it is not clear whether flow means the object which is created based on the L4 and L7 analysis of IP flows. The term IP flow means the actual user plane traffic flow, which passes through the Flexi ISN.

Figure 4 illustrates the relationship between the flow and flow specifications. The Flexi ISN configuration (the service profile) defines the L4/L7 flow specifications. Flows are instantiated based on the traffic analysis. The flow specification may include wild cards, while the flow always contains the exact signature for the related L4 and L7 flow. Thus, there can be multiple active flows related to the flow specification. Multiple service com-ponents can be linked to the flow specification, but the correct service component is determined when the flow is instantiated. A flow is always linked to only one PDP context, so there may be multiple flows linked to different PDP contexts and mobile sub-scribers. One PDP session can have many active flows and they define the flow profile of the PDP session.

26 DN04134609Issue 7-3 en


Id:0900d805808d42a5


Figure 4 Flows and flow specifications

The charging class associated with the flow defines the charging functionality (see Section Differentiated charging). The active flow maintains the charging state:

• the counter values for all metering methods • the quota allocated for the flow • the timers related to the flow

Other state information might also be attached to the flow. For example, in the Trans-mission Control Protocol (TCP) flows, the state information stores the current TCP state of the TCP flow.

When the Flexi ISN receives a packet the following steps are executed to determine the L4 flow for the packet:

1. The existing flows are checked. If a match is found the procedure is stopped, as the flow for the packet has been determined. The matching is based on the uplink and


27



Id:0900d805808d42a5

downlink IP address/port and the protocol identifier in the IP packet. Note that in this case both the uplink and downlink port numbers are used, while in the next step only uplink port numbers are relevant.

2. If no flow matched with the packet, the Flexi ISN will check the L4 flow specifications from the service profile. Matching is based on the protocol identifier IP address and port. The packet is discarded if there is no match. The best match algorithm is explained in Section L4 flow specification.

3. There are one or more service components, which are linked to the L4 flow specifi-cation. Each service component is linked to a different service. When the PDP context was activated, the user profile of the mobile subscriber defined the list of active services. The service profile controls the activation of the services based on the roaming, access type and location. Each service has a different priority. The Flexi ISN will select the service component linked to the service that has been acti-vated for the mobile subscriber and has the highest priority. If there are two active services with the same priority, the service ID is used to determine the priority between these services.

4. The gating policy is part of the service component configuration. It defines whether traffic is allowed to pass or not.

5. Before a new flow is created, the Flexi ISN checks how many flows have already been activated for the mobile subscriber. During this step, unused flows might be removed. If there is no space left for the new flow, the packet is discarded. The Flexi ISN's capacity dimensioning guarantees that this situation should occur only in very rare cases.

6. The final step is to create the flow for the traffic. The flow will always be defined as an exact IP address, port number and IP protocol identifier, although the related L4 flow specification might use wild card expressions. In addition, the L4 flow specifica-tion is a global configuration object, while the flow is subscriber-specific. Thus, there might be multiple flows related to one L4 flow specification. If secondary PDP contexts are used, the flow is linked to one of the secondary PDP contexts of the PDP session.

The flow might also be created dynamically, based on the control traffic related to the L7 application. Some L7 applications have separated the signalling and payload traffic flows. The control flow uses predefined port numbers, but the payload traffic flows are negotiated dynamically. If the Flexi ISN is able to analyze the L7 traffic of such applica-tions, the Flexi ISN will create the flow(s) related to the payload traffic flows before the actual payload traffic starts. In this way, the correct match is already found in step 1 (see above) when the first packet is received.

Determining the right L7 flow consists of the following steps:

1. The matching L7 flow specification is determined. The matching is based on the URL and hit trigger. The latter attribute is used to differentiate between different pro-cedures of the related L7 protocol. For example, in the MMS analysis, sending and receiving MMS messages is usually linked to different L7 flow specifications based on the hit trigger attribute.

2. When the matching L7 flow specification has been found, the related L7 service component is determined. If no L7 service component is found, the packet is dropped. This step works in a similar way as for the L4 traffic. In other words, the Flexi ISN selects the L7 service component that has the highest associated priority and the related service is activated for the mobile subscriber.

28 DN04134609Issue 7-3 en


Id:0900d805808d42a5


Also, the L7 flows are always linked to the related L4 flow. The L7 flows contain even more L7-specific state information.

2.3 Service awareness in 3GPP reference architectureStarting from release 6, 3GPP has also introduced some service awareness to its 3GPP reference architecture. The Flexi ISN provides a more advanced service awareness implementation while still being fully compliant with the 3GPP specifications. The Flexi ISN service awareness is very flexible and also compatible with the 3GPP roadmap con-cerning future specification of service awareness. For example, the introduction of the Gx interface in Flexi ISN did not require any major changes to the service awareness architecture.

In the 3GPP reference model, traffic analysis is implemented in the traffic plane function (TPF). 3GPP specification 23.125 defines the TPF functionality. 3GPP allows the imple-mentation of TPF either as a separate node, or as a functionality integrated to the GGSN. The Flexi ISN has selected the latter alternative. This enables the maximum cost saving in deployment, because no extra hardware is required for TPF functionality.

The terminology used in 3GPP is different from the concepts used in the Flexi ISN. Table 2 defines the mapping between the main terms and concepts.

3GPP Flexi ISN

charging key The Flexi ISN uses the service identi-fier and rating group identifier as a charging key. It is possible to use the service identifier, or the rating group, or both.

charging rule The flow specification and service component linked to it define the charging rule.

Flow Based Charging (FBC) policy functions

FBC policy functions are defined based on service selection. The initial service selection is defined by the user profile and additional service selection is done based on the access, location, and roaming awareness.

gating Gating is defined by flow initiation rules, which are defined in service components

IP network connection Since the GGSN and TPF functionality are integrated in the Flexi ISN, the IP network connection is defined by one PDP context.

packet flow The Flexi ISN uses the term flow. It can be either an L4 or an L7 flow.

Table 2 3GPP and Flexi ISN terminology


29



Id:0900d805808d42a5

3GPP specification 32.251 defines how service awareness is applied to charging. Online charging related to service awareness is defined in 3GPP specification 32.299. The Flexi ISN implementation is based on all these 3GPP specifications.

2.4 Service awareness in the Flexi ISN architecture

2.4.1 Layered controlFigure 5 shows the layered control model in the Flexi ISN architecture.

Figure 5 Service control layers

There are three different layers in Flexi ISN. The service profile defines the static rules for the whole Flexi ISN. It defines the basic rule set. Subscriber-specific rules are defined in the user profile. If the default user profile is used, the user profile is can be defined either statically, or dynamically. Dynamically defined user profiles are fetched by Flexi ISN from an external registry during the PDP session activation (that is, when the primary PDP context is activated). It is possible to update the user profile during the PDP session using an external registry. The dynamic state is defined in the flow profile, which is specific for each PDP context.

This layered model also applies to the network level. This is illustrated in the Figure 6 where a combined PCS/OCS server is used and in Figure 7 where there is a separation of the PCS and OCS servers. The service profile is configured in the Flexi ISN and defines also the default user profile. If a non-default user profile is used, it must be

predefined charging rule Predefined charging rules are part of the service profile.

service identifier The Flexi ISN uses the same term.

service data flow A set of flows, which are linked to the same service component.

service data flow filter The L4 flow specification defines the classification for L4 traffic in the Flexi ISN. There is no corresponding term for the L7 analysis in the 3GPP model, because L7 analysis is not in the scope of the 3GPP reference model.

3GPP Flexi ISN

Table 2 3GPP and Flexi ISN terminology (Cont.)

30 DN04134609Issue 7-3 en


Id:0900d805808d42a5


received from an external registry using the LDAP, RADIUS, separate Gx, or Gx over Gy interface. The policy control server (PCS) and online charging system (OCS) provide additional policy and credit control through the Gx and Gy interfaces, respectively. The 3GPP defined PCRF implemented either as a distinct PCS server or as a combined PCS/OCS server provides additional policy through the separate Gx or through the Gx over Gy interface respectively. The chain of control is clear. The default rule is defined in the service profile and the user profile defines which rules apply for a certain PDP session. These rules may be overridden by policy, or credit control decisions coming from the PDF, or the OCS.

Figure 6 External control

Figure 7 External control with separate Gx interface

One key design-principle in the Flexi ISN is to separate the traffic analysis from the policy. Traffic analysis classifies traffic using fixed procedures. It operates based on the flow specifications, which are part of service profiles, but these flow specifications simply define a classification policy for the traffic analysis. The actual traffic analysis always operates using the same basic principles.

This separation of analysis and policy is a powerful design principle, because it allows a lot of flexibility, while avoiding customization needs for actual implementation of traffic analysis. Operators can freely select a policy that is suitable for their business needs by applying different policy decisions. The layered control architecture makes it possible to


31



Id:0900d805808d42a5

define these decision on various levels, enabling cost saving, because not all decisions need to be defined using external control interfaces.

2.4.2 Service awareness architectureFigure 8 shows the logical view of the service awareness architecture. There are two management systems. Session management controls the PDP sessions. Session man-agement interacts with control elements, which provide user profiles and credit/policy control. Session management also handles the interaction with charging elements. The local service profile defines the default rules, which can be overridden by the control decisions coming from external control nodes. The final control decision is passed to the analysis modules. Analysis classifies the traffic into flows, which are then handled to flow management. Service awareness is embedded in the basic GGSN functionality, which provides GTP termination in the Gn/Gp interface and various IP connectivity options in the Gi interface. Modular architecture enables the use of the same framework also in other access methods, where GTP termination is replaced with a generic RADIUS-based NAS interface.

Figure 8 Service awareness architecture

2.5 Charging architectureFigure 9 shows the logical view of the charging architecture related to service aware-ness. Offline and online charging use the Gz and Gy interfaces defined in 3GPP speci-fication 23.125. The Charging Gateway (CG) does not provide any control, so the Flexi ISN simply sends charging data records (CDR) through the Gz interface. The Flexi ISN integrates the GGSN and the traffic plane function (TPF) in one node, so actually the Ga

32 DN04134609Issue 7-3 en


Id:0900d805808d42a5


and Gz interfaces are combined. Online charging is two-directional. The Flexi ISN reports the service use to the online charging system (OCS) using the Gy interface, but the Flexi ISN also receives credit control decisions from the OCS. These credit control decisions are passed from the Diameter Credit Control (DCCA) module to the charging module.

The charging module is the centralized control point for the charging of individual PDP contexts. Because of the distributed hardware architecture in the Flexi ISN, there are actually multiple independent centralized charging modules, which control disjoint sets of PDP contexts. The charging module collects the raw metering data and refines the data with session information before forwarding the data to the charging interfaces. The final interface-specific charging data is produced in the interface modules. The charging module also passes the credit control decisions to the metering system.

The dashed line in Figure 9 separates the charging component from other architectural components. Session management interacts with the charging module. It passes the session information (for example, the current SGSN address) to the charging module. A credit control decision might affect session management and in this case the charging module will inform session management about required changes to the session state (for example, termination of PDP context due to insufficient quota). Similar co-operation takes place between the metering module and traffic analysis. The metering module passes quota to traffic analysis and traffic analysis reports the used volumes and hits in the flows. Whenever volume, or hits are reported to the metering module the time metering is automatically invoked .

Figure 9 Charging architecture


33



Id:0900d805808d42a5

2.6 External control elements

2.6.1 Offline charging elementNokia Charging Gateway (CG) collects and consolidates the charging records from the SGSN and the Flexi ISN nodes, and delivers them to a post-processing system. In the 3GPP reference model the Ga interface is used between the GGSN and the CG, while the Gz interface is defined between the traffic plane function (TPF) and the CG. The Flexi ISN integrates the GGSN and TPF into a single element so the Flexi ISN commu-nicates with the CG using a single interface. The Flexi ISN supports standard G-CDRs, which provide the GGSN level of charging. If all access points are using service aware-ness, there is no need to enable the generation of G-CDRs in the Flexi ISN, because the SA-CDR contains both the GGSN and TPF level charging data. Charging into differ-ent wallets is implemented by including the wallet ID in the SA-CDR.

The Flexi ISN supports the generation of CDRs also in cases where online charging is enabled. The charging configuration defines which CDR types are generated in different situations. If online charging is used, the CDR will contain information about it to avoid double charging. Based on this information the CG knows if it should use the charging data for actual charging, or if the charging data is provided, for example, for statistical reasons.

2.6.2 Online charging elementThe Flexi ISN supports the Gy interface specified in the 3GPP standards and enables interoperability between all online charging systems (OCS) that are compliant with the interface specification. Nokia Online Service Controller (OSC) is one of the nodes that implements the OCS functionality. The OCS is the network element used in online charging. Online charging is based on a quota, which controls the service use of the mobile subscriber. The OCS can be used in the following cases:

• online prepaid chargingThe OCS guarantees that the prepaid customer does not exceed the use limits. The charging is handled through the OCS.

• online credit control for post-paid charging (this requires Diameter)The OCS guarantees that the post-paid customer does not exceed the use limits. In this case the OCS only provides the monitoring. The actual charging is handled in the CG.

• wallet-specific charging, where at least one of the wallets requires credit control

The Flexi ISN also supports online charging based on the Nokia Siemens Networks pro-prietary Remote Authentication Dial In User Service (RADIUS) for backward compatibil-ity reasons.

The OCS is an optional network element. If the OCS is missing, online charging is not supported in the Flexi ISN and all the mobile subscribers are charged using the offline charging interface with the CG.

2.6.3 User profile retrievalThe Flexi ISN supports two interfaces for retrieving the user profile from an external reg-istry. The Lightweight Directory Access Protocol (LDAP) interface is used towards Nokia Siemens Networks Profile Server (NPS). Nokia Siemens Networks Profile Manager

34 DN04134609Issue 7-3 en


Id:0900d805808d42a5


(NPM) handles the actual management and provisions the user profiles to the NPS, which then acts as an LDAP repository for the Flexi ISN. There is no interface between the Flexi ISN and the NPM.

The other alternative interface is based on RADIUS authentication and use of Nokia Siemens Networks vendor-specific attributes, which define the user profile in the Access Accept message. For more information about the RADIUS interface, see the RADIUS Interface Description, Nokia Siemens Networks Flexi ISN.

The user profile retrieval interface is defined in the access point configuration. It is also possible to use a local default user profile for all subscribers so using an external registry for storing user profiles is optional. Note, however, that truly subscriber-specific defini-tions are not possible without an external registry.

If the user profile is not received from an external registry using either the RADIUS, or LDAP interface, the Flexi ISN uses the default profile. Some of the user profile defini-tions might also be received from the OCS. The OCS can define the following parts of the user profile in the initial Credit-Control-Answer message (CCA):

• list of active servicesThe OCS can define the list of services only if the user profile is not fetched using the RADIUS, or LDAP interface. The requested APN is automatically selected as the primary APN.

• charging profile, including the walletsNote that if the OCS sets the charging profile to postpaid, the online charging inter-face is not disabled.

2.6.4 Provisioning service profileThe service profiles must be configured locally in the Flexi ISN through the Voyager, or the Command Line Interface (CLI).

2.6.5 Interworking with IMSThe design of service awareness takes into account the IP Multimedia System (IMS). The Flexi ISN enables alternative strategies related to interworking with the IMS. It is possible to use a dedicated access point for IMS services and disable service aware-ness in the access point. This is the approach to be taken when IMS services are used over IPv6. However, this would violate the single access point name principle, see Section Single access point model. For this reason, the design of the Flexi ISN allows the usage of IMS services also in the same access point where service awareness is enabled.

For example, the charging control for IMS services can be defined similarly to other ser-vices. First, static or default decisions can be defined in the service profile. Session Ini-tiation Protocol (SIP) traffic can be charged differently from other traffic. Additional control decisions can be defined in subscriber-specific user profiles where, for example, certain IMS services could be disabled. Roaming, location and access awareness can be used to introduce additional control logic. Finally, the IMS system can interact with the OCS and dynamically define a credit control policy for IMS services through the Gy interface. All these decisions must take into account the capability of traffic analysis. If a certain service cannot be clearly identified, it is not possible to make policy control decisions that only apply to that service.


35



Id:0900d805808d42a5

Policy for the Services and Quality of Service is done through the combined PCS/OCS or through the separate Gx interface. For this purpose P-CSCF connects to PCS (com-bined PCS/OCS) via the Rx interface. For more information about the combined PCS/OCS implementation in Flexi ISN refer to Diameter Credit Control Application, Interface Description in Nokia Siemens Networks ISN, while for the separate Gx inter-face implementation refer to the Diameter Policy Control Application, Interface Descrip-tion in Nokia Siemens Networks Flexi ISN.

2.6.6 Push proxy gatewayThe push proxy gateway (PPG) is a logical network element, which is defined in Open Mobile Alliance (OMA) WAP standards. The PPG is responsible for sending WAP Push messages to the user equipment. The PPG is typically implemented as part of the WAP gateway. More information about the notifications and dialogues can be found in Section Notifications.

2.7 Service engine

2.7.1 L4 analysisThe purpose of the transport layer (L4) analysis is to classify traffic according to the L3 and L4 properties: IP addresses, port numbers and protocol types. L4 analysis enables efficient differentiation for traffic types, because only the IP and TCP/UDP headers, or both, need to be analyzed. However, L4 analysis is not possible in the following cases:

• when hit-based metering is required • when based on static configuration, that is, the used traffic flows are negotiated

dynamically between the user equipment and the other peer. For example, in streaming applications based on RTSP, the actual RTP flows might use any port number so it is not possible to detect RTP flows without analyzing the RTSP traffic and in that way figure out what are the port numbers used in the RTP flows.

Many protocols use fixed port numbers. The full list of port numbers that have been reg-istered to the Internet Assigned Numbers Authority can be found from http://www.iana.org/assignments/port-numbers. Hundreds of different protocols can be analyzed simply based on L4 analysis alone, while only certain L7 protocols require explicit L7 analysis.

L4 analysis has two main tasks:

• It determines the L4 flow (see Section Flow). • Once the flow has been determined, it applies the policy for the flow.

The latter action has the following subtasks:

• applying the gating decisionDepending on the gating policy, the traffic is allowed to pass or is blocked.

• applying credit controlIf online charging is enabled, the credit control policy manages the quota for the flow and L4 will block the traffic unless there is a quota.

• differentiated chargingL4 analysis reports the volume to the metering system after each passed packet. then, the metering system also updates the time counting.

36 DN04134609Issue 7-3 en


Id:0900d805808d42a5


• applying L7 analysisIf L7 analysis is enabled for the flow, packets are passed to the L7 analysis before they can be forwarded.

• traffic redirectionIf the Automatic redirection L4 traffic licence is activated, then the traffic can be redi-rected using the redirect address or redirect port, or both, configured in the L4 service component.

• service switchingL4 forwards uplink traffic to the right Gi connection.

2.7.2 L7 analysisThe Flexi ISN supports analysis of certain application layer (L7) protocols. L7 analysis is used for the following purposes:

• hit-based metering for L7 protocols. For example, each HTTP request to a certain URL(s) generates a hit.

• differentiated charging for L7. For example, based on the accessed URL, the charging is differentiated. This is useful in case the differentiation cannot be imple-mented in L4.

• detecting dynamically negotiated traffic flows related to the application. For example, media flows used in Real-Time Streaming Protocol (RTSP) cannot be detected based on L4 flow specifications.

Similarly to L4 analysis, the two main tasks for L7 analysis are to determine the right L7 flow (actual classification) and to apply the defined policy to the L7 flow. L4 analysis passes traffic to L7 analysis only if the L7 analysis has been enabled in the L4 flow spec-ification.

The applied policy depends on the analyzed L7 protocol, because some actions are not feasible for all L7 protocols. The following actions are supported:

• applying gating policySimilarly to L4 analysis the gating policy defines whether traffic is blocked, or not.

• applying credit controlIf online charging is enabled, the credit control policy defines a quota for the flow and L7 will block the traffic unless there is a quota.

• differentiated chargingL7 analysis reports volume, or hits, or both to the metering system after each passed packet. Then, the metering system also updates the counting of time. For some L7 protocols, time-based metering needs to be explicitly controlled by L7 analysis (for example, RTSP).

• redirection, or traffic modification, or bothFor DNS, WAP, HTTP, and RTSP traffic, it is possible to redirect traffic, or modify the original traffic flow by replacing the original URL with a new value, or by inserting additional headers.

The Flexi ISN supports the following L7 protocols in L7 analysis:

• DNS • e-mail

L7 analysis is supported only for Simple Mail Transfer Protocol (SMTP), which is used for sending e-mail. Receiving e-mail typically uses IMAP4 and POP3, but it is


37



Id:0900d805808d42a5

not feasible to define hits for these protocols. Thus, IMAP4 and POP3 are analyzed only on L4 level.

• FTP • HTTP • i-mode (e-mail and browsing) • MMS over WAP 1.x • MMS over WAP 2.0 • RTSP/RTP • Push to talk over cellular • WAP 1.x and WAP 2.0 • BitTorrent • eDonkey2k • DirectConnect • FastTrack • MSNP (MSN messenger) • OSCAR (AOL messenger) • SIP • Skype • XMPP (Jabber) • YMSG (Yahoo messenger)

The details related to the traffic analysis of each respective L7 protocol (except for the P2P protocols) are described in the relevant sections. For information about P2P anal-ysis, see P2P Traffic Management in Nokia Siemens Networks Flexi ISN.

Note that even if some L7 analysis is supported in the Flexi ISN, L7 analysis should not be enabled unless there is a real need for it. For example, basic L4 analysis is often suf-ficient for SMTP and only if hit-based metering needs to be applied for SMTP traffic is there a real need for L7 SMTP analysis. For more information, see Service Profile Con-figuration, Application Guide.

2.7.3 Proxy L7 analysisThe Flexi ISN supports three L7 analysis modes: basic, proxy and P2P analysis. The choice between these modes is configured in the L4 flow specification when the L7 analysis for the traffic flows is enabled. In the proxy mode the Flexi ISN functions as a transparent proxy with the following properties:

• It is a proxy server. A proxy server is an active component in the traffic flow.The L7 analysis modules in the Flexi ISN act as connection end points towards the user equipment and the application function. For example, with Transmission Control Protocol (TCP), the Flexi ISN acts as a connection end point for the TCP connection that originates from the user equipment. The Flexi ISN creates another connection to obtain the content from the application function. Consequently, two completely separate TCP connections exist between the client and the server. With WAP 1.1 (which is based on User Datagram Protocol, UDP) the data flow consists of two separate parts, similarly as with TCP: one flow delivers the data from the user equipment to the Flexi ISN and another from Flexi ISN to the WAP gateway.

• It is a transparent device on the IP protocol level. The IP addresses and (TCP/UDP) port numbers used for communication with the client (mobile terminal) and with the server always refer to the actual communication end point, not to the Flexi ISN.

38 DN04134609Issue 7-3 en


Id:0900d805808d42a5


The following use case describes the TCP connections in proxy L7 analysis:

1. The Flexi ISN receives IP packets from a user equipment (UE). The packets request a new TCP connection between the UE and a content service.

2. L4 analysis detects that L7 proxy analysis is required for this traffic and forwards the packets to the proxy analysis.

3. The proxy analysis module accepts the connection from the client, using the desti-nation IP address in the original connection attempt. When the Flexi ISN sends packets to the UE it uses the IP address and port number of the content server as the source address. The UE assumes it is talking directly to the server because the IP addresses are not changed.

4. The Flexi ISN receives the content request from the UE and creates a TCP connec-tion to the server. The Flexi ISN uses the IP address and port number of the UE as the source address in IP packets and the content server sends packets to the UE IP address.

The characteristics of a TCP connection subject to L7 analysis appear different when observed at the client and at the server. For example, the TCP sequence numbers are different at the client and at the server, and the amount of data in the individual network packets might be different.

In the WAP 1.1 protocol stack, based on the UDP protocol, maintaining the connection state is slightly different and more complicated than in TCP, but the principle is same.

2.7.4 Basic versus proxy analysisTable 3 shows which analysis modes are supported for various L7 protocols. For some protocols, the Flexi ISN supports both basic and proxy analysis, while for other protocols only one of the modes is supported.

L7 protocol Basic Proxy P2P analysis

DNS x -

FTP - x

HTTP x x

i-mode x x

MMS x x

PoC x -

RTSP x x

SMTP - x

WAP x x

BitTorrent x

eDonkey2k x

DirectConnect x

FastTrack x

Table 3 Supported analysis modes for L7 protocols


39



Id:0900d805808d42a5

The basic and proxy analysis have the following differences:

• Proxy analysis supports the generation of hits based on the Multi-purpose Internet Mail Extension (MIME) type detected in the L7 traffic. Basic analysis does not support MIME analysis.

• Proxy analysis supports redirection to two configured URLs: payment required URL and deny URL. The first URL is used when there is no quota for traffic flows. The deny URL is used when the action in the service component is 'deny'. This redirec-tion functionality is supported for i-mode, WAP 1.x, WAP 2.0, HTTP, and MMS. Basic analysis only supports redirection for HTTP to the payment required URL.

• Proxy analysis is able to produce an L7-specific error response to the terminal when the action is 'deny' in the service component and the L7 analysis does not support redirection.

• Proxy analysis is able to provide redirection of RTSP traffic based on the Gi connec-tion used.

• Basic analysis is able to redirect WAP 1.x to an IP address defined in the service component. It is able to redirect MMS messages to another MMSC defined in the URI rewrite field.

• Proxy analysis does not support the concept of content volume. Volume metering is based on L3 data.

• For basic analysis, L3 or L7 metering can be selected. If L7 volume metering is dis-abled, basic analysis counts L3 volume. If L7 volume metering is enabled, basic analysis counts L7 volume. L7 metering has two alternatives: only the payload, or both payload and headers.

• Basic analysis supports uplink and downlink hits, which are configured with hit trig-gers. Proxy analysis generates hits based on fixed rules, which are not configurable. There is no separation of uplink and downlink hits in proxy analysis.

• Proxy analysis is able to redirect and modify (URI rewriting) HTTP/WAP 2.0 traffic according to the configuration in the L7 service component.

The basic and proxy analysis use fundamentally different implementations, which cause some differences in these analysis modes. Basic analysis is done in the Flexi ISN kernel code, which means that the impact on packet forwarding capacity is minimized. On the other hand, basic analysis offers a more limited functionality, because basic analysis is simply sniffing the passing traffic and it is unable to modify, for example, the TCP data flow.

Proxy analysis, however, is implemented in multithreaded processes, which act as fully transparent proxies for L7 traffic flows. Using the proxy mode in analysis makes it

MSNP x

OSCAR x

SIP x

Skype x

XMPP x

YMSG x

L7 protocol Basic Proxy P2P analysis

Table 3 Supported analysis modes for L7 protocols (Cont.)

40 DN04134609Issue 7-3 en


Id:0900d805808d42a5


possible to modify the traffic flows because the proxy terminates the TCP connection ini-tiated from the user equipment and opens another TCP connect towards the application server. This flexibility comes with an additional performance penalty because each end-to-end TCP connection will reserve two TCP connections in the Flexi ISN and the number of available TCP connections for this purpose is limited. This fact should be taken into account when the decision is made about whether to use L4, or L7 analysis and choosing between proxy and basic analysis.

2.7.5 P2P analysisThe basic and proxy mode analyses assume that the analyzed protocol can be already detected based on L4 analysis. Once the L4 analysis forwards the traffic to the L7 anal-ysis, all the packets belong to the analyzed protocol and the purpose of the L7 analysis is to make differentiation within a single L7 protocol, based on the properties of the L7 protocol (such as the requested URI). This assumption does not hold for peer-to-peer (P2P) applications, which typically use dynamically selected port numbers. The P2P traffic is often designed to hide from traditional traffic analysis. In P2P analysis the goal of the analysis is to monitor and control the usage of a certain P2P protocol and there is less need to make differentiation within a single P2P protocol.

To cope with the P2P protocols, which cannot be analyzed using traditional methods and need to be managed differently, the Flexi ISN also supports a third analysis mode, P2P analysis, which uses a complementary third approach in traffic analysis.

When P2P analysis is enabled, the L7 protocol is not yet identified based on L4 analysis. Instead, the L4 analysis forwards to the P2P analysis all traffic flows that match the flow specifications which have P2P as the L7 protocol. P2P analysis is typically enabled for all the traffic flows where the traffic cannot be classified based on L4 analysis. Each flow may be detected as a certain P2P protocol, or it might also remain unknown if the P2P analysis cannot find any matching P2P protocol. If there are no P2P matches, the settings for the '*' URI are obeyed. If the '*' URI setting has not been defined, the IP packets are dropped. Differentiation based on P2P protocols is defined in the L7 flow specifications and traffic flows related to single L4 flow specification may be related to multiple P2P protocols.

P2P analysis uses less accurate detection methods, such as application signatures and heuristical analysis. P2P analysis cannot be used to get fully accurate charging, and hit-based charging is not supported in P2P analysis.

For more information about P2P analysis, see P2P Traffic Management in Nokia Siemens Networks Flexi ISN.

g In response to market changes CIC/IP Gateways Product Line concentrates its Flexi ISN development efforts on bandwidth management solutions based on Fair Usage Policy and complements Flexi ISN integrated P2P detection capabilities with external product suite for P2P.


41


Service switching

Id:0900d805806f305b

3 Service switching

3.1 Standard access point modelAn access point defines the entry to the IP networks (for example, Internet, private intra-nets). In other words, it defines the Gi connection to the data networks. The access point name (APN) identifies the access point. When a PDP context creation is requested the SGSN gives the APN to the Flexi ISN.

Figure 10 illustrates, in an abstract way, how the access point works. It defines two pipes: one between the user equipment (UE) and the Flexi ISN, and another between the Flexi ISN and the data networks. For example, in the GPRS access network, the first pipe uses the GTP tunnel, while the other pipe might use GRE tunneling, or plain IPv4. The access point binds these two pipes and creates a connection between the UE and the data networks.

Figure 10 Access point in Flexi ISN

The access point configuration in the Flexi ISN includes the following attributes:

• the tunnelling used in the Gi interface for the user-plane traffic • the routing instance used • the IP address allocation method for the UE

If the IP address is allocated locally in the Flexi ISN, the access point configuration defines the IP addresses that can be allocated to the UE.

• RADIUS authentication and accounting servers • the maximum number of active PDP contexts for the access point • DNS servers of the access point • charging profile

The charging profile configuration in the access point is ignored if the user profile is fetched from NPS/NSM, or the RADIUS server. If the value of the charging profile in the access point is 'HLR', the charging profile is defined by the charging character-istics, which have been passed from the HLR through the SGSN.

• timeout for the PDP contextTwo timers are defined: the idle lifetime defines how long the PDP context can remain idle and the session lifetime defines how long the PDP context can be used in general. If any of these timers expire, the PDP context is terminated. The use of the timers is optional. If, for example, the session timer is undefined, there is no maximum lifetime for the PDP context.

3.2 Single access point modelIn the 3GPP standards only one access point can be associated with each PDP session. One charging session handles one PDP context session and, as a result, there are lim-itations in the differentiated charging capabilities.

This has lead to problems, because if the operator wants to differentiate the charging between IP flows, a separate access point is required. This, in turn, leads to a higher

42 DN04134609Issue 7-3 en


Id:0900d805806f305b

Service switching

number of access points in the network (for example in the DNS, HLR and GGSN). Access point provisioning in the network requires testing by the operator. In addition, the access point must be provisioned to the UE and the mobile subscriber must activate a new PDP context whenever a new service is accessed. There may also be an upper limit defined in the HLR for how many access points can be configured for each subscriber. Corporate access also requires a separate access point.

The Flexi ISN has introduced the single access point concept to solve this problem. Only one access point must then be configured to the UE and is visible to the subscriber. The concepts context access point and service access point are used to illustrate how the single access point concept works. The Gn (access) and the Gi (data networks) are sep-arated. The context access point is the part of the access point that is visible to the UE on the Gn side. The connectivity to data networks and services is provided through service access points.

The Flexi ISN also supports the activation of multiple access points in each PDP session. There can be several different Gi connections activated for each PDP context. Service switching is the functionality where the Flexi ISN determines the correct Gi con-nection for each IP flow. Separate Gi connections are required when tunnelling is used for a particular service and IP flow, or when different IP address spaces are used (NAT).

The Flexi ISN service engine enables differentiated charging in combination with the single access point name (APN). Every uplink, or downlink packet the Flexi ISN receives is classified according to an L4, or L7 flow, or both. This means that each IP flow can be charged differently. Differentiated charging enables rating and charging IP flows inde-pendently. It is possible, for example, to apply a different rating for streaming and brows-ing. It is even possible to apply post-paid charging for some IP flows of the PDP context, while other IP flows are handled as prepaid traffic.

When one access point is associated to one service type, it is possible to define the QoS for services based on the access point. In that way, the different QoS requirements of the services can be taken into account even if the UE does not support the QoS. The service-based QoS feature makes it possible to define the QoS for different services without the need for additional and unnecessary access points. The QoS for each service can be defined and the Flexi ISN is able to modify the QoS of the PDP context based on the services currently used. In other words, the single APN model handles the QoS issues as well.

In Figure 11 the UE is seen to be connected to multiple services through the service access points, but for the UE this is completely transparent, because it only sees the context access point.


43


Service switching

Id:0900d805806f305b

Figure 11 Flexi ISN single access point for all services

The context access point and service access point are modelling concepts and are not actually visible in the Flexi ISN configuration and implementation. They are used to simplify the presentation of the single access point model. In the configuration there are only access points. The access point configuration always defines both the Gn and Gi connectivity, so one access point might act as both the context access point and service access point. The access point gets different roles based on the service selection in the user profile.

3.3 Access point aliasesThe Flexi ISN supports the association of access point name (APN) aliases, making it possible to refer to the same access point with many symbolic names. The alias names must have a proper DNS entry.

The use of access point aliases makes it easier for operators to administer name changes for the APNs. The mapping of different alias names in the Flexi ISN to one APN eliminates the need to change user UE settings.

3.4 Context-prohibited access pointsThe Flexi ISN supports context-prohibited access points. A normal access point is visible to the user equipment (UE) and can be included in the PDP context activation request. The UE cannot use a context-prohibited APN in the PDP context activation request. This type of APN is not visible in the DNS system and can be considered as hidden.

3.5 Access point rolesWhen multiple access points are activated for each PDP session, one of the access points is the primary and the rest are the secondary access points. If only one access point is activated, then it is the primary access point.

The main difference between the primary and secondary access point is the visibility of the access point to the UE. The access point configuration defines how the IP address

44 DN04134609Issue 7-3 en


Id:0900d805806f305b

Service switching

is allocated to the UE and the DNS servers used in the PDP session. The UE cannot have more than one IP address and two DNS servers.

With the Flexi ISN single access point concept this problem is overcome. The IP address of the UE and the DNS servers are based on the primary access point configuration. The secondary access point can also allocate IP address to the UE and it can define alter-native DNS servers, but they are transparent to the UE.

Note that the primary and secondary attribute of access points is not configurable. Any access point can act as a primary and secondary access point. The user profile defines the role of the access point. One of the services listed in the user profile is the primary service and the access point linked to the primary service will be used as the primary access point. Other access points that are activated are then automatically secondary access points.

Figure 12 illustrates the case when multiple access points are used in one PDP context.

Figure 12 Multiple access points in Flexi ISN

When the UE requests activation of the PDP context, the request contains an APN. This access point, the requested access point, is the context access point. The actual Gn connectivity might not, however, be defined by the access point configuration of the requested access point. This is defined by the primary access point, which in many cases is the same as the requested access point. The primary access point also defines one of the service access points. Network access translation is never used in the service access point defined by the primary access point. Additional service access points can be defined by the secondary access points. The mode of a requested APN in the Flexi ISN configuration defines how the primary access point is selected:

• normalIn this case, service awareness is not supported and no user profile needs to be determined. The requested access point is the primary access point.

• GGSNThe user profile is defined by the local configuration and is fixed for all mobile sub-scribers. The user profile then lists only the activated services. The requested access point is the primary access point. The OCS might override the set of acti-vated services, but the OCS cannot change the primary access point.

• PCRFThe user profile is defined by the local configuration and is fixed for all mobile sub-scribers. The user profile then lists only the activated services. The requested access point is the primary access point. The PCS might override the set of acti-vated services, but the PCS cannot change the primary access point

• NPSThe user profile is defined by Nokia Siemens Networks Profile Server (NPS) and it can be different for each mobile subscriber. If the user profile is not stored in the NPS, the default user profile can be used in a way similar to the GGSN mode access point. The primary access point is defined in the user profile. When the user profile


45


Service switching

Id:0900d805806f305b

is fetched, the requested access point is used as a search key together with the MSISDN, or IMSI so the requested access point might not even be activated for the PDP context.

• RADIUSThe RADIUS server defines the user profile, which can be different for each mobile subscriber. The primary access point is defined in the user profile. The RADIUS server might use any of the RADIUS attributes to select the correct user profile for the mobile subscriber (for example, IMSI, MSISDN, IMEI, requested APN).

When the Flexi ISN acts as a classic GGSN, only one access point is related to each active PDP context. Service awareness removes this limitation and any number of access points can be used for each active PDP context.

3.6 Transparent service authentication Each secondary access point might use different service-specific authentications, trans-parent to the end user. In the secondary access point, it is possible to define a RADIUS, or L2TP authentication setting for that particular Gi connection. The service-specific parameters such as user name and password can be retrieved from a RADIUS, or LDAP server as part of the user profile. This procedure needs no end user interaction and is fully transparent. Actual authentication, that is, decisions about whether a mobile user is allowed to access a service, is handled in NPS, or a RADIUS server. If the service is not listed as active service in the user profile, the mobile subscriber cannot use the service.

3.7 IP address managementThe Flexi ISN needs to manage the IP addresses of user equipment (UE), because in many cases the IP address is the only identifier used to determine the correct PDP context for the ingress downlink packets.

The UE might already have an IP address when the PDP context is created. In this case, the Flexi ISN needs to verify that the IP address of the UE is allowed. The verification is based on the configured IP address range of the access point. This case is common when a PDP context is created through the NAS interface, where the IP address is allo-cated already, for example, in a legacy GGSN.

The Flexi ISN also supports IP address allocation for cases when the UE does not yet have any IP address. The access point configuration defines the used IP address allo-cation method.

Multiple access points can be activated when the PDP context is activated. One of those access points is the primary access point and the rest are the secondary access points. When the PDP context activation is received, the IP address allocation uses the access point configuration of the primary access point. In most cases, the primary access point is defined by the APN passed from the user equipment. In some cases, however, the related user profile might change the primary access point to another access point. In any case, the IP address allocated to the primary access point will be passed to the UE.

IP address allocation can also be enabled for the secondary access points. If another IP address is allocated for the UE to the secondary access point, it is not passed to the UE, and the Flexi ISN performs network access translation (NAT) for all traffic that is routed from, or to the secondary access point. The use of NAT must be avoided because it

46 DN04134609Issue 7-3 en


Id:0900d805806f305b

Service switching

breaks some application protocols (see RFC 2663, 2993 and 3027 for more informa-tion).

In some cases the use of NAT can be avoided in the secondary access point. Based on the access point configuration, it is also possible to select the policy that forces the sec-ondary access points to use the same IP address for a PDP context as the primary access point . The configuration is further explained in Access Points in Nokia Siemens Networks Flexi ISN. From the point of view of the secondary access point, the IP address allocated to the primary access point is handled in a similar way as static IP addresses. That is, if the IP address of the UE belongs to the configured static IP address range of the secondary access point, the same IP address is allocated to the secondary access point and no NAT will be used whenever service switching forwards packets to the secondary access point.

To prevent IP address overlapping, NAT also requires that the primary and the second-ary access points are located in different routing instances.

3.8 Packet forwardingAfter the flow has been activated the packets can be transmitted. Both uplink and downlink traffic are accepted while the flow is active. Each service is linked to one access point, which defines the Gi connection (that is, the data network and access method towards the selected data network). Thus, the flow indirectly defines the Gi con-nection to be used for the uplink packets. If there is only one active access point, service switching is trivial.

Figure 13 illustrates an example of service switching. The UE tries to use four different flows. Service switching analyzes the packets on the edge of the Gi interface (see above). The user profile allows the use of WAP, MMS and HTTP, but streaming traffic is not included in the user profile. Thus, one of the flows is blocked. In the same figure, two access points are used: pipes 1 and 2 represent the different Gi connections. WAP and MMS use pipe 1, while the streaming data and WWW use pipe 2. Service switching makes it possible to use these two Gi connections over the same PDP context.


47


Service switching

Id:0900d805806f305b

Figure 13 Service switching

3.9 DNS redirectionEach access point (AP) can have its own domain name system (DNS) server settings. The DNS servers visible in the UE are allocated by the primary AP. However, different DNS server settings in the secondary APs can still be used. The Flexi ISN can redirect the DNS query to the correct DNS server based on the content (application layer) of the DNS query. The destination address of the DNS query can be changed to the DNS server if defined in the secondary AP. The DNS redirection is transparent to the mobile. When the response comes back from the DNS server of the secondary access point, the Flexi ISN replaces the DNS server address with the original DNS server defined in the primary access point.

Figure 14 illustrates how the DNS redirection works for a query. The UE sends a DNS query and the Flexi ISN redirects the DNS query to another DNS server. When the DNS server responds, the Flexi ISN modifies the response so that it appears to be coming from the original DNS server.

48 DN04134609Issue 7-3 en


Id:0900d805806f305b

Service switching

Figure 14 DNS redirection


49


Service control

Id:0900d805806f305f

4 Service control

4.1 GatingService control can define gating, that is, service authorization. In that case, the Flexi ISN will block the traffic. Cases where gating can be used include the following:

• subscriptionsThe traffic is blocked until the subscription has been activated. Gating may be also required when the subscription either expires, or has a usage limit.

• credit controlThe online charging system (OCS) may also define gating. Traffic should be blocked if the mobile subscriber has no funds, or if the OCS is controlling the use of subscrip-tions.

Gating can be implemented using different levels of service control:

• Gating can be implemented directly in the service profile, or access point configura-tion. For example, mobile-to-mobile traffic may be blocked based on the access point configuration. The service profile may also block traffic to certain sites uncon-ditionally, that is, it is not possible to send traffic to these sites in any situation. Roaming, location and access awareness also provide gating possibilities.

• Gating can be based on the services listed in the user profile. If the service is not enabled in the user profile, the related traffic flows may be blocked completely.

• As mentioned previously, OCS may define gating.

The gating functionality is also about passing traffic. The action in the charging rule may also define that traffic may be passed normally.

The local gating control is defined in the service component. The configuration is defined in the flow initiation rule in the L4 service component. The following alternatives are pos-sible:

• Traffic is always allowed to pass. • Traffic is allowed to pass if the first packet of the flow is going in the uplink direction. • Traffic is allowed to pass if the first packet of the flow is going in the downlink direc-

tion. • Traffic is silently blocked. • Traffic is blocked and the TCP reset is sent to the user equipment.

There are fewer alternatives for the L7 service component:

• Traffic is always allowed to pass. • Traffic is silently blocked. • The original traffic flow is blocked, but depending on the L7 protocol, the traffic is

either redirected, or an application-specific error indication is sent to the user equip-ment.

The local configuration allows flexible gating control, because the gating action is defined in the service component. This means that the gating action is defined by active services. Location, access and roaming awareness makes it possible to have different gating actions based on the location of the user equipment, the used access technology (2G, 3G, or WLAN) and/or the roaming status.

Note that if the traffic flow does not match any of the configured flow specifications, the traffic is always blocked. It is a good practice to define one default L4 flow specification

50 DN04134609Issue 7-3 en


Id:0900d805806f305f

Service control

for traffic flows that do not match with any of the other flow specifications. In a similar way, it is recommended that whenever L7 analysis is enabled in an L4 flow specification, there is a default L7 flow specification that allows non-special traffic to pass.

4.2 RedirectionThe Flexi ISN L4 analysis supports traffic redirection. The traffic is redirected according to the configured redirection address, or port fields, or both, in the L4 service compo-nent. L4 traffic redirection is possible regardless of whether the L7 analysis is enabled or not (no L7 protocol has been selected) for a specific flow. L4 traffic redirection is des-ignated for the L7 protocols listed below:

• HTTP • proxy HTTP • WAP • proxy WAP

The Flexi ISN does not support simultaneous L4 and L7 traffic redirection.

The Flexi ISN L7 proxy analyzers support the following traffic redirection and modifica-tion types:

• HTTP/WAP2.0/WAP1.x static redirection triggered by lack of quota, or a service denial

• RTSP redirection based on the used service access point • externally controlled HTTP/WAP2.0/WAP1.x dynamic redirection and URL rewriting • HTTP/WAP 2.0 L7 redirection and URI rewriting according to the configuration in the

L7 service component

The Flexi ISN L7 basic analyzers support the following traffic redirection types:

• HTTP/WAP2.0 static redirection triggered by lack of quota • externally controlled HTTP/WAP2.0 dynamic redirection and URL rewriting • WAP1.x L7 redirection according to the configuration in the L7 service component

The redirection functionality in basic L7 analysis allows redirection of WAP 1.x traffic according to the configured redirection address and port fields in the service component. DNS traffic can also be redirected.

4.3 NotificationsL7 redirection triggered by a lack of quota, or service denial is one way to provide inter-action with the user equipment (UE), but it cannot be used in cases where the underlying traffic is not HTTP, or WAP. Push messaging provides a generic approach for imple-menting notifications towards UEs.

Push messaging implementation depends on the nature of the bearer sessions. If the bearer sessions are not constantly open, the push message cannot be delivered over the bearer session connection. Network-initiated PDP contexts are not supported in the Flexi ISN so the only way to deliver the push message is to use SMS if there is no open PDP context. The delivery method for push messages also depends on the capabilities of the used push proxy gateway (PPG).

The Flexi ISN implements support for push messaging based on the Push Access Protocol (PAP) interface towards the PPG. When a notification needs to be sent to the


51


Service control

Id:0900d805806f305f

UE, the Flexi ISN sends a PAP request to the PPG and the PPG delivers the notification to the UE.

In online charging based on Diameter, the service use is based on the quota that is requested from the online charging system (OCS). If the mobile subscriber has no money in the account, the OCS can send an indication that the Flexi ISN should send a notification using the PPG. The mobile subscriber can then deposit money into the account and receive more quota for the service use. The content of the notification message is locally configured, but it might contain a field where the redirection URL received from the OCS is inserted.

Notifications can also be sent when a service is used for the first time during the active PDP context. The content of the message is configurable and it can be different for each service.

4.4 Access awarenessAccess awareness is a service awareness feature. The Flexi ISN is a multi-access gateway because it supports 2G, 3G and WLAN based on the GTP and NAS interfaces. Not all access technologies are equivalent because the bandwidth, QoS and charging might be different.

When GTP is used to create the PDP context, the RAT (radio access technology) type value defines the access type. If the NAS interface is used, 3GPP-RAT-Type is used in RADIUS to indicate the access type. It is also possible to configure the default access type for each separate instance of the NAS interface.

A minimal way of having access awareness is to use a different requested access point name (APN) for different access types. That way the activated services can be selected based on the requested APN. In addition, the access technology can be passed in the charging interfaces and RADIUS, so the external network elements can take into account the access technology.

The APN-based solution works only if no handover is supported between different access technologies. This is not currently true for 2G and 3G. In the future, handovers between GPRS and WLAN will also be possible.

Access awareness in the Flexi ISN means that the activation of the services is based on the access type. The service profile defines all the services supported by the Flexi ISN. For each service, it is possible to define the access types where the service is allowed. Access awareness takes into account three different access technologies:

• GSM/EDGE Radio Access Network (GERAN) • UMTS Terrestrial Radio Access Network (UTRAN) • 3GPP WLAN

For example, it is possible to define that a service is allowed only in UTRAN. If the mobile subscriber has subscribed to this service and the PDP context is initially activated in GERAN, the service is not allowed. If, later there is a handover to UTRAN then, the service becomes active.

Access awareness is based on the local Flexi ISN configuration. The user profile does not have any access-specific parameters.

52 DN04134609Issue 7-3 en


Id:0900d805806f305f

Service control

4.5 Location awarenessLocation awareness is a service awareness feature. Based on the location of the UE, the services are handled differently. The charging can be based on a different rating group, or the access to the service can be completely blocked.

The Flexi ISN gets the location of the user based on the User Location Information, or Routing Area Identity (RAI) attributes, or both, in the GTP, or RADIUS messages. Both of these attributes are optional so it is possible that user location is undefined.

The location is defined in the Flexi ISN with area configuration. There are different location area levels:

• country level – the area is defined using the mobile country code (MCC) • operator level – the area is defined using the mobile network code (MNC) • location area level – the area is defined using the location area code • cell level – the area is defined using the cell global identification, or the service area

identifier

Note that based on location awareness, it is possible to define a more detailed roaming control. If the granularity of the location areas is MCC+MNC, the operator can define that a certain service is allowed only if the subscriber is roaming in certain operator networks. In that way, it is possible to take into account preferred roaming partners.

Routing areas cannot be supported in the Flexi ISN, because the SGSN does not include the routing area information in the routing area identity (it contains only the PLMN ID). The actual location area might combine different location levels.

Once the location area is defined in the Flexi ISN configuration, it is possible to use these location areas to control when a certain service is enabled. If an area set is attached to a service, the terminal can use the service only if it is located in the config-ured area set.

Note that location awareness has limitations. Location updates are received in PDP context modifications and the location update itself is not a reason for PDP context mod-ification. The location is updated only if the QoS, or SGSN is changed in the PDP context.

4.6 Roaming awarenessRoaming awareness is a service awareness feature. Based on the roaming status of the user equipment (inbound and outbound roaming) the services are handled differently. The charging can be based on a different rating group, or the access to the service can be completely blocked.

The roaming status is determined based on the PLMN ID of the SGSN and the mobile subscriber. The PLMN ID of the SGSN is received in the RAI attribute over GTP, or RADIUS. The PLMN ID of the mobile subscriber is included in the IMSI. The Flexi ISN configuration defines what is the home PLMN.

Roaming awareness is supported by the Flexi ISN using the roaming status as one trigger when selecting the service component.

4.7 Treatment ClassesOne of the main features in the Flexi ISN is the support for treatment classes (TREC). TREC is a Nokia Siemens Networks proprietary solution for QoS control which is under


53


Service control

Id:0900d805806f305f

of either a service-based QoS control license or a network-based QoS license. For service-based QoS, TREC applies per access point and/or per flow, while for network-based QoS it applies per access point and can be retrieved from RADIUS or NPS server.

TREC is a combination of the most relevant 3GPP R99 QoS parameters: traffic class, traffic handling priority, maximum and guaranteed bit rate for both uplink and downlink directions, and allocation retention priority. Each TREC is a unique combination of these parameters. A maximum of 10 different TRECs can be configured in Flexi ISN.

TRECs enable the mobile network provider to differentiate the traffic in the network into predefined QoS 'pipes'.

The following functionalities are relevant to the TREC:

• base TREC for access pointsThe base TREC is used to define the default QoS handling for the traffic. When there is no traffic with an explicitly defined TREC, the base TREC will be used for the PDP context. Alternatively, the access point configuration may also disable the use of TRECs. The TREC functionality is supported only for IPv4 access points.

• TREC associated with flowsIn the Flexi ISN the TREC is linked to the L4 flow specification. If there is traffic related to the L4 flow specification, the Flexi ISN should offer at least the QoS, defined by the related TREC. As there might be traffic related to multiple L4 flow specifications linked to different TRECs, the active TREC is the one with the highest QoS.

• network-initiated QoS modification • service-based QoS: When Flexi ISN detects traffic that is matched to a flow with

higher TREC, it will start the QoS modification towards the SGSN. Alternatively, when Flexi ISN notices that there is no longer traffic that requires the current TREC, the Flexi ISN will downgrade the TREC by starting the PDP context mod-ification procedure. Note, however, that the Flexi ISN cannot upgrade the QoS to a higher level than the one which was originally requested from the SGSN.

• network-based QoS: Network-based QoS modification can also be triggered by the RADIUS server sending a new TREC to Flexi ISN.

g TREC is not supported on the Gx over Gy or the separate Gx interface. The QoS information AVP is used instead.

• secondary PDP context supportFor secondary PDP contexts the functionality is different. During the secondary PDP context activation, TREC configured in the access point is not applicable. If there are enough resources in Flexi ISN, the QoS request from SGSN applies instead. In the case of service-based QoS control, if there is no traffic requiring the requested QoS for a period of time, Flexi ISN will update the QoS profile to a lower level.

For more information about the NSN propietary TREC solution and network-based QoS refer to Quality of Service in Nokia Siemens Networks Flexi ISN. The 3GPP standard-ized QoS control over separate Gx interface is described in the Diameter Policy Control Application, Interface Description in Nokia Siemens Networks Flexi ISN.

54 DN04134609Issue 7-3 en


Id:0900d805806f305f

Service control

4.8 Service bandwidth limitThe service bandwidth limit is a concept used in Flexi ISN that allows the operator to control the bandwidth consumed by certain services according to a configurable set of values, in both uplink and downlink data flow direction. This is possible by the discarding of packets in services that exceed the predefined limits.

The service bandwidth limit is a globally enabled feature. The bandwidth limits are con-figurable for each service separately. By default there are no service bandwidth restric-tions.

The service bandwidth limit for layer 7 flow configurations only is applicable for layer 7 flows linked to layer 4 flows of the P2P, proxy FTP, proxy RTSP, and RTSP protocols. For all other cases only the service bandwidth limit values set on the layer 4 service con-figuration will apply.

For more information on the configuration of service bandwidth limit, see Service Con-figuration in Nokia Siemens Networks Flexi ISN.

For more information on service bandwidth limit, see Service bandwidth limit in Quality of Service in Nokia Siemens Networks Flexi ISN.


55


Differentiated charging

Id:0900d805808c042b

5 Differentiated charging

5.1 Basic functionalityDifferentiated charging is closely related to service switching and it is the other pillar of the service awareness functionality. Differentiated charging makes it possible to classify traffic based on an L4 (transport layer) and L7 (application layer) trigger and meter the L4 and L7 flows based on volume, time and hits. Each flow can then be charged differ-ently.

Each L4 and L7 flow specification is linked to a charging class through a service com-ponent. Together the charging class and the service can be used to differentiate the charging of distinct IP flows.

5.2 Online chargingThe main difference between offline and online charging is the use of quota in online charging. The Flexi ISN reports metered use in both offline and online charging, but a quota is used only in online charging. The quota defines to what extent the mobile sub-scriber is allowed to use the different services. The quota is allocated to each service component and also to the whole PDP context. The quota is defined for each metering type separately.

The Flexi ISN supports several different charging profiles for online charging. The charging type can be:

• post-paid with credit controlThe online charging interface is used to control the service use, but the actual charging is done with the offline interface. The online charging system (OCS) can control that the mobile subscriber does not exceed a use limit for certain services.

• prepaidThe mobile subscriber has paid in advance for the use of the services. The services are allowed while the mobile subscriber has still funds in the OCS. When there is no money in the prepaid account, the OCS does not grant quota for the Flexi ISN.

• prepaid with credit cardThis charging profile is similar to the previous one, but the mobile subscriber can be billed afterwards, if necessary. The difference is crucial for error recovery handling.

Online charging is based on the Diameter Credit Control Application (DCCA) protocol, which is a typical client-server protocol. The Flexi ISN acts as the client and requests a quota from the OCS using Credit-Control-Request message (CCR). The Flexi ISN sends a CCR when the following trigger condition is met:

• A PDP context is created.Only the quota for the whole PDP context is requested at this point. This trigger is not used for always-on PDP contexts.

• A PDP context is updated.A PDP context update may affect the rating so the Flexi ISN must check whether the quota limits have changed or not.

• A PDP context is deleted.At this point the final use is reported. In the always-on case, the final use is already reported when the PDP context has been idle for a long time.

56 DN04134609Issue 7-3 en


Id:0900d805808c042b


• A flow instance is created.A quota for the flow is requested.

• A flow instance is deleted.The used quota is reported.

• The validity time has expired.The OCS can define for how long the quota is valid. When the timer expires the Flexi ISN must request quota again and report the use so far.

• The OCS can trigger a CCR any time by sending a Re-Authorisation Request (RAR), or by returning a certain status code.

• The quota runs out.

It is possible to disable some of these triggers (see Diameter Credit Control Application, Interface Description for more information).

The following procedures can be initiated when the OCS has responded to the CCR:

• The whole PDP context is terminated. • The related service is blocked. • The related service is considered to be free and no further quota is requested for the

service. The Flexi ISN does not report the use of the free services. • If the OCS indicates that the returned quota is the final one, the Flexi ISN sends a

notification to the user equipment through the Push Access Protocol (PAP) inter-face.

• In most cases, the OCS returns the quota. The Flexi ISN allows use of the service as long as there is some quota. When the quota runs out, the Flexi ISN requests more quota from the OCS.

5.3 Offline chargingOffline charging basically consists of three steps:

1. When the packets go through the Flexi ISN, they are metered. The metering data is stored in the internal counters.

2. A charging data record (CDR) is generated based on the values of these counters.3. The CDR is passed to the Charging Gateway (CG) for further processing.

The 3GPP specification has defined the Ga interface for charging purposes. It is the interface between the Flexi ISN and the CG. The interface uses the GTP’ protocol.

The Flexi ISN supports two different types of CDRs: the G-CDR and the SA-CDR. Normal charging is based on the G-CDR, which contains the PDP-context-specific volume-based measurement data. The G-CDR contains data related to the whole PDP context. The service awareness functionality has introduced the SA-CDR. The SA-CDR supports all the measurement types used in differentiated charging and the charging can be flow-specific.

The 3GPP standard defines the CDR format with an ASN.1 definition. The Flexi ISN does not use ASN.1. Instead, it supports a TLV-based CDR format. Also, plain text and XML format are supported.

The Flexi ISN supports several different charging profiles in offline charging. The charging type can be:

• normal post-paidThe mobile subscriber receives a bill after the service has been used.


57



Id:0900d805808c042b

• prepaidThis charging method is sometimes called server-based, or off-line prepaid to dis-tinguish it from the online prepaid, which is handled based on online charging. In this case, the mobile subscriber has paid in advance for the use of the services.

• hot billing • flat rate

The charging profile is clearly indicated in the CDR. If CDRs are produced for subscrib-ers who are actually billed based on online charging, the CDR will clearly indicate which traffic is under credit control in the OCS. This way double billing is avoided.

Offline charging also supports tariff changes and toll-free networks. The access point configuration can define four toll-free networks. If a packet is destined for the toll-free network, the packet is not included in the normal volume-based measurement data in the G-CDR. The G-CDR reports the measured toll-free traffic separately from other measurement data. The toll-free networks affect only the content of the G-CDRs. When service awareness is enabled, there is no need to define toll-free networks because service awareness enables a much more flexible way of defining which traffic is free. The charging class configuration is then used to indicate that some traffic flows are not metered at all.

5.4 MeteringMetering is the process where traffic analysis produces the raw counters for the Flexi ISN charging system. The actual charging data for online and offline charging interfaces is then produced from this metering data.

The following metering types are supported:

• volume-based metering • hit-based metering • time-based metering

The Flexi ISN supports multiple metering methods for each charging class. In offline charging all metering methods cab be automatically enabled. The online charging inter-faces only reports the counters where the respective metering method has been enabled.

In some cases, there is a need to meter uplink and downlink time separately. The main use case is Push to talk Over Cellular (PoC), where the uplink time would define for how long the mobile subscriber was talking and the downlink time would define for how long the mobile subscriber was listening to the call. Diameter Call Control Application (DCCA) supports the separation of the uplink and downlink directions for volume only so the solution is to define two charging classes for each L4/L7 service component. If only one charging class is defined, it applies to both uplink and downlink directions.

5.4.1 Volume-based meteringThe volume metering function in the Flexi ISN counts bytes from user data and reports them as used units to the online and offline charging interfaces.

The Flexi ISN collects volume metering in three different analysis categories:

• network layer/ transport layer (L3/4) analysis: highest performance • application layer (L7) basic analysis: high performance; performed in the kernel

58 DN04134609Issue 7-3 en


Id:0900d805808c042b


• application layer (L7) proxy analysis: moderate performance; performed in multi-threaded processes

Separate counters may be enabled for uplink and downlink traffic. Alternatively, only one of the directions may be metered.

Depending on the analyzer's volume metering type, different parts of the packet are included in the count. With traffic volume, the complete packet is metered. With content volume, only part of the packet, that is, the L7, or application content is metered. When using volume metering for both the L3/L4 and L7 analysis of one flow, different charging classes must be used for L3/L4 and L7.

g The service shaper (used to limit QoS) commits L7 and L3/L4 traffic to charging sepa-rately, so volume differences in CDRs can arise, for example, if the traffic to mobile equipment has arrived on Flexi ISN, but it is not forwarded because of connection errors. In this case, the statistics regarding shaped packet drops (“Shaped service packets PDP gone”) are updated.

With L7 analysis, packets that do not contain L7, or application data are not counted. The counted bytes are not always committed as used units immediately. The moment the counted bytes are committed varies depending on the analyzer. The counted bytes will not affect credit control nor will they visible in the charging interfaces until they have been committed.

All packets that are fragmented at IP level will be defragmented before further analysis. Volume metering will not take place before the packet has been defragmented.

g If both traffic volume and content volume are enabled at the same time for one charging class, the class must not be used for both the L3/L4 and L7 analysis of one flow.

5.4.1.1 Volume metering with L3/4 analysisL3/L4 analysis counts only traffic volume, that is, the total number of bytes in the packet, including IP and TCP/UDP headers. Retransmissions are counted as well.

L3/L4 analysis does not count content volume, so content volume must not be enabled for a charging class linked only to an L3/L4 analysis.

The bytes are committed as used units immediately after they are counted.

5.4.1.2 Volume metering with basic L7 analysisBasic analyzers have two metering options. The first one is Content-L7 volume metering and the second one is L3 volume metering. The default option is L7 volume metering enabled.

L7 Volume metering enabledBasic L7 analyzers do not include L3/L4 headers (IP and TCP/UDP) in the volume count. Only the actual L7 message is counted. In the Flexi ISN terminology this type of volume is called content volume.

Basic L7 analyzers do not count traffic volume so traffic volume must not be enabled for a charging class linked only to a basic L7 analysis.

Optionally, the header part of the L7 message can be configured to be omitted from the count. The L7 message is divided into the header and payload differently depending on the analyzer.


59



Id:0900d805808c042b

• L7 Volume metering with basic WAP 1.x analysisThe WTP and WSP headers are included in the L7 header count. All bytes following the WSP header are counted as L7 payload.WAP signalling traffic, such as acknowledgements and transaction aborts, that do not contain L7 content are not included in the volume count. Also, connection handling messages in connection-oriented WAP, such as Connect, ConnectReply and Disconnect, are not included in the volume count.Retransmitted packets are not counted.WAP 1.x analysis is divided into two subcategories: MMS and browsing.In MMS analysis, only messages belonging to successful transactions are counted. That is, if a reply contains result code other than OK, no bytes are counted for that transaction. The counted bytes are committed when a successful reply is received. The same rule is applied to both sending and receiving MMS messages.WAP browsing has a dedicated analysis and both successful and unsuccessful transactions are counted. The bytes are committed as used units after each packet, or in the case of a segmented message, at the start and end of the message and during the message if the configurable option Layer 7 reporting threshold is greater than zero and the counted, but yet uncommitted bytes for the particular direction (uplink or downlink) exceeds it. Note that this differs from proxy WAP 1.x analysis where the sum of uplink and downlink bytes is used in this calculation.

• L7 Volume metering with basic HTTP analysisAll bytes after the TCP/IP header and before two consequent CRLF characters (that is, an empty line) are considered as header in an HTTP message. All bytes following the header are considered as payload.Retransmitted TCP segments of the HTTP message are not included in the volume count. Only the first transmission will be counted. TCP segments arriving out of order will not be analyzed before the missing intermediate segments have been received. Since retransmitted segments are not counted, the reported byte count matches exactly the size of the HTTP message that the originating application has sent and which the destination application will receive, that is, no TCP/IP headers, or signalling are included.The HTTP analysis is divided into two subcategories: MMS (over WAP 2.0) and browsing. In browsing analysis the bytes are committed as used units immediately when they are analyzed and counted.In MMS analysis, the basic principle is the same as with WAP 1.x MMS analysis. That is, no volume is committed for unsuccessful transactions. After the reply header has been received containing a result code indicating success, the bytes counted so far will be committed. After that, the rest of the bytes belonging to the reply are imme-diately counted and committed after they are received. The same rule applies to both sending and receiving MMS messages.

L7 Volume metering disabledWhen L7 volume metering is disabled the following changes in counting occur: basic analyzers include the full IP length in the volume count, as well as the IP and TCP/UDP headers (traffic class must be configured to count volume); the Content Volume option in the charging class configuration page does not appear when the L7 volume metering is set to Disabled.

60 DN04134609Issue 7-3 en


Id:0900d805808c042b


• Volume metering with basic WAP 1.x analysisThe full IP length is included in the volume count.WAP signaling traffic such as acknowledgments and aborts can be included in the volume count. The Free Signaling option in WAP 1.x configuration must be set to Disabled. These messages are reported to the charging class matching the URL of the WAP request.Retransmitted WAP packets are reported when the option Free Retransmission is set to Disabled in the WAP1.x configuration.The WAP control messages (Connect, Connectreply and Disconnect) can also be metered. Since these messages do not include URL information, a special URL should be configured (http://*/#WAP#WAPCONTROL#). Alternatively, if such a URL is not configured, these messages will be reported to the charging class linked to a catch-all L7 flow.

• Volume metering with basic HTTP analysisAll bytes indicated by the message’s IP length and all retransmitted TCP segments of the HTTP message are included in the volume count. The retransmitted TCP segments are reported to the charging class of the most recently detected L7 flow within the L3 flow.TCP Establishment/Termination and signaling are reported to the most recently detected charging class.

g If a TCP connection is closed without detecting any charging class, TCP signaling data is not metered.

• MMS volume meteringMMS can be transported over the HTTP, or WAP1.x protocol. Both analyzers report the MMS volume even if the status code states that the MMS transaction was not successful.

5.4.1.3 Volume metering with L7 proxy analysisWith proxy analysis, all connections are terminated in the Flexi ISN. Because of this, the traffic volumes and messages at the Gn and Gi sides are not identical. For this reason, the proxy analyzers count all traffic from the Gn side. This prevents the end user from being charged for any data that the Flexi ISN might add to the content at the Gi side (for example, additional HTTP headers for server information).

L7 proxy analyzers do not count content volume so content volume must not be enabled for a charging class that is linked only to an L7 proxy analysis.

• Volume metering with proxy WAP 1.x analysisThe proxy WAP 1.x analyzer counts full WAP packets, containing IP, UDP, and WTP/WSP headers.Connection handling messages in connection-oriented WAP such as Connect, Con-nectReply and Disconnect are also counted.Counting retransmitted packets is a configurable option.Counting signalling traffic, that is, the acknowledgements and transaction aborts, is a configurable option. The bytes are committed as used units at the end, and during, the transaction if the configurable option L7 reporting threshold is greater than zero and the sum of the counted, but uncommitted uplink and downlink bytes exceeds it. Note that this differs from kernel WAP 1.x analysis where only the bytes of the par-ticular direction (uplink or downlink) are used in the calculation.


61



Id:0900d805808c042b

• Volume metering with proxy HTTP analysisAll packets within the TCP connection during the transaction are included in the volume count, including TCP and IP headers, retransmissions and TCP signalling.The bytes are committed as used units immediately when they have been counted.

5.4.2 Hit-based meteringHit-based metering is only used when L7 analysis is enabled. Recording hits functions slightly is differently in the basic and proxy analysis modes. When basic L7 analysis is used, the L7 flow specification defines which events will trigger the generation of a hit. In addition, it is possible to meter uplink and downlink hits separately. When proxy L7 analysis is used, the hit generation logic is not configurable and there is no support for separating uplink and downlink hits. The proxy analysis will produce hits whenever an L7 transaction is successful.

The web environment does not provide a simple way of building applications with com-pletely transactional characteristics so the generation of a hit does not necessarily mean, for example, that the content item has been delivered successfully to the user equipment. For example, a server can respond with a successful status code, but the user equipment can terminate the connection before it has actually received the content.

The hit-based charging model is the best model for services that are accessed in a series of distinct events. Each hit can be considered to have a separate price. A good example is a service providing web, or WAP access to news articles.

The services charged with the hit-based model must consist of transactions with the fol-lowing properties:

• The user is charged when the service request is completely successful. • If the service request fails (even partially), charging should not take place. • An incomplete transaction must not provide the user with partially usable content. • The duration of each individual access is limited in time (and data volume), reducing

the risk of interrupted transfers. • The value of each content item is relatively low.

A service providing web or WAP access to, for example, news articles, meets the char-acteristics quite well. Sending an MMS, or an e-mail message is a transaction; the message is either sent completely or not at all, which makes these services suitable for the hit-based charging model.

Downloading large files such as MP3s, or videos, or receiving multimedia streams, must never be considered transactional because partial delivery of the content item is possi-ble.

Protocols supporting confirmed delivery present another problem; if the charging takes place when the transfer is confirmed to be successful, as with File Transfer Protocol (FTP), a connection problem near the end of the transfer can provide the customer an almost complete and sometimes usable content item for free.

Using hit-based charging should always be considered carefully. In many cases, data volume, or subscription-based charging may be better charging policy choices.

5.4.3 Time-based meteringThe metering of time in the Flexi ISN is based on recording the timestamp (the time of arrival) of chargeable user data packets. The counter for used time units is incremented

62 DN04134609Issue 7-3 en


Id:0900d805808c042b


by computing the difference between two timestamps: the recorded and the current timestamp. Time calculations in the Flexi ISN are done in the time metering function.

The time metering function in the Flexi ISN is called at the same points where the counted volume is committed as used units, as described in Section Volume-based metering. Thus, like volume metering, time metering will produce different results depending on the used analysis type.

When the time metering function is called, the current timestamp is recorded and the used time units counter is updated as follows:

• If the time elapsed since the last call is less than the configured quota consumption timer (QCT) (also called the silence period), the used time units counter is cumu-lated with the time elapsed since the last call.

• If the time elapsed since the last call is more than, or equal to the QCT, the value of the configured quota consumption time is added.

• If there has not been any previous calls, the used time units counter is not incre-mented.

The effect of QCT expiration is shown in the Figure 15.

Figure 15 Effect of QCT expiration in Flexi ISN

The granularity of the timestamps captured by the Flexi ISN is one second. This means that if two timestamps are captured 0.9 seconds apart, but still within the same second (as seen from the real-time clock), no time is charged.

The time metering function is called due to any of the following online, or offline charging triggers:

• PDP context update, or deactivation • CDR volume, hit, or time limit • quota validity time expiration


63



Id:0900d805808c042b

• reauthorization, or termination request received from the OCS • quota holding time/service closed timeout expiration • manual CDR generation • session inactivity timeout in the always-on mode

Note that in these cases the ending time of the QCT is retained so that the QCT will expire at the same time as it would have without the trigger in between, except for the following triggers that cause termination of the service instance in the Flexi ISN:

• PDP context deactivation • termination request received from the OCS • quota holding time/service closed timeout expiration • session inactivity timeout in the always-on mode

Time quota exhaustion will not be detected at the precise moment of exhaustion unless the time metering function is called at that moment (which can happen because of the reasons listed above). No dedicated timer currently exists for detecting the exhaustion. However, the OCS may set a validity time, or use the reauthorization request to ensure that the time metering function is called at the moment of exhaustion, or before.

Figure 16 shows how an interrupting PDP context update affects time metering. (The QCT is assumed to be long enough not to expire during the transaction).

Figure 16 Effect of interrupting a PDP context update on time-based metering

The time meter is a property of the charging class, not the transaction, or flow. This means that if multiple transactions (URI, or flow) share the same charging class, they will also share the same time meter.

In offline charging (CDR) the time counter is sent to the Duration field while in online charging (CCR) the time counter is sent to the CC-Time attribute-value pair.

64 DN04134609Issue 7-3 en


Id:0900d805808c042b


The Flexi ISN can be configured to meter the time separately for uplink and downlink packets. This can be achieved by using two rating groups, one for uplink and one for downlink time. In this case, time will be reported in CDRs in the Uplink Time and Downlink Time fields. Those two fields will be reported in separate containers, one for each rating group. The container that reports the uplink time does not include the Downlink Time, or the Duration fields. The container that reports the downlink time does not include the Uplink Time, or the Duration fields.

5.5 Time step chargingTime step charging is a new way of counting the time a service has been accessed. When the first packet of the service is let go, a predefined time interval ('step') is always charged no matter what the subscriber behavior is during this interval. After this interval a new step will be charged when the next packet is let go. This predefined time interval can be rating group specific. Time step charging is supported in both online and offline charging.

Whenever a trigger in the charging interface (for example the DCCA Validity Time, CDR Time Threshold, or volume quota expiration) takes place during an ongoing step, the charging interface reports the ongoing step at the time the trigger is met and the Flexi ISN keeps a memory of the ongoing step validity also after reporting. This means that the subscriber can still access the service for the time corresponding to the part of the step following the trigger at no extra cost since the subscriber has been charged already for the ongoing step.

Whenever a tariff change happens within an ongoing step, the step is counted and recorded in the CDR, or reported in the DCCA as with other metering methods. The Flexi ISN keeps a memory of the validity of the step and the subscriber can still access the service for the time corresponding to the part of the step following the trigger at no extra cost since the subscriber has been charged already for the ongoing step at the tariff that was valid at the beginning the step. The Flexi ISN starts to count a new step and applies the new tariff only when there is a packet flowing outside the already counted step.

Whenever a QoS/SGSN/RAT change happens within an ongoing step, the step is counted and recorded in the CDR, or reported in the DCCA as with other metering methods. The Flexi ISN keeps a memory of the validity of the step and the subscriber can still access the service for the time corresponding to the part of the step following the trigger at no extra cost since the subscriber has been charged already for the ongoing step. The Flexi ISN starts to count a new step only when there is a packet flowing outside the already counted step.

For the Flexi ISN to charge properly when the quota holding timer (QHT), or the Service Closed Time Out is used for a rating group that is metered with time step charging, the QHT, or the Service Closed Time will always be bigger than the value of the step. This will ensure that the QHT, or the Service Closed Time never interrupts the step.

If a PDP context is closed in the middle of an already charged step the remaining part of the step is lost.

Whenever a DCCA CCR message is sent, or a CDR container is closed in the middle of a step, any volume and hits consumed in the part of the step following the DCCA trigger, or CDR trigger are reported in the next DCCA CCR message, or CDR container together with the volume/hits counted for the next step.


65



Id:0900d805808c042b

The time steps are reported in seconds in the CDR and DCCA interface by using the standardized CDR fields and DCCA attribute-value pairs that are used to report other forms of time.

The silence period must not be used with time step charging. Active time metering and time step charging are two different metering methods, which are mutually exclusive. The time step charging method is an evolution of the active time charging enabled by the silence period.

For instructions on how to configure time step charging, see Section Configuring the charging class in Service Configuration in Nokia Siemens Networks Flexi ISN.

5.6 MIME-based chargingThe multipurpose Internet mail extension (MIME) defines the means of encoding binary content for transfer and communicating the type of the content item to the recipient. MIME is commonly used in Internet applications, especially in e-mail, web and WAP. The MIME content can consist of several parts, which can be of different types. For example, e-mail messages containing attachments are almost always delivered in MIME format.

The Flexi ISN can charge HTTP and WAP browsing, as well as SMTP and MMS mes-sages, according to the MIME types if the proxy analysis mode is used. MIME-type charging is based on configuration tables that contain the MIME types, such as ‘text’ or ‘image’, and the associated hit counts. When a MIME content item is encountered and MIME type based charging is enabled, the Flexi ISN finds the matching entry in the MIME type table. The number of hits specified for the content type is added to the charging class counter. The charging class is always defined in the L7 service compo-nent so the configuration table only controls the number of generated hits. Different hit counts can be entered for each of the application protocols (HTTP, WAP, SMTP, and MMS). Additionally, different hit counts can be configured for incoming and outgoing traffic (with the exception of SMTP, which is used for outgoing traffic only).

MIME type based metering has a special handling for text parts: if the content item has more than one text part, the Flexi ISN always charges for only one text part. This behavior is most apparent in SMTP and MMS messages, which may contain several text parts (for example, text attachments in e-mail messages), but the Flexi ISN charges for one text part.

A MIME content item can have a layered structure. For example, the multipart and message MIME types can contain other multipart, or message items, leading to a content structure with several MIME layers. The MIME analysis in the Flexi ISN operates on the topmost layer; Flexi ISN does not perform deep analysis within the complex MIME content types. As an exception to this rule, the Flexi ISN does analyze the first level within multipart MIME content items in HTTP POST requests to facilitate HTTP file uploads.

For example, the MIME type table for an e-mail message with a text part (MIME type text/plain) and two images (MIME type image/jpeg) contains the following values:

• text: 1 • image: 3 • application: 4

The e-mail message would cause the value of the charging class counter defined for e-mail messages to be incremented with the value corresponding to 7 charging hits (1 for

66 DN04134609Issue 7-3 en


Id:0900d805808c042b


the text/plain part, 2 * 3 for the images and 0 for applications). Note that the charging class counter would have increased by only one hit if the MIME type based charging had been disabled.

Setting the field value to 0 in the MIME-based charging table permits the customers to access the particular content type for free. For example, with HTTP, if the hit count field for the MIME type image is set to 0, but the other fields contain values, the customers can download all images for free. MIME type based charging requires downlink hit-based charging to be used. Volume, or time based charging cannot be used alone.

Enabling charging according to MIME types and recipient patterns simultaneously, causes the charging result to be determined in the following way:

1. The number of hits according to the MIME types is counted first.2. The multiplication factors according to the recipient patterns are added.3. The values obtained in steps 1 and 2 are multiplied and the result is added to the

charging class counter.

When expressed in mathematical notation, the steps above correspond to the formula:

p = (n1 + n2 + n3 + …) * (r1 + r2 + r3 + …)

where p is the price (the final number of hits charged), n1...nn are the MIME type multi-pliers and r1...rn are the recipient address pattern multipliers.

g Charging MMS, or e-mail messages according to the MIME types can lead to large numbers of hits being charged from the subscribers. In particular, when charging according to the recipients and MIME types simultaneously, the charging result can be surprising.

Enabling this feature must always be carefully considered.

It is possible to disable MIME type based metering if there is no need for it.

5.7 MMS message charging according to the sender

g This feature is only applicable to uncompressed MMS messages. The sender informa-tion in compressed MMS messages is also compressed, becoming unreadable to Flexi ISN. In this section, the expression MMS message implies being a uncompressed MMS message.

MMS messages can be charged according to the sender of the message. The Flexi ISN has an additional set of rules for this purpose. The MMS sender rules contain a sender address pattern, in which wildcards are allowed and two charging classes (the main charging class and a class for combined charging).

MMS charging according to the sender is mainly intended for messages delivered from content services (content-to-peer MMS messages). Such a service, for example, could offer weather forecasts delivered daily to the subscriber in an MMS message.

MMS messages have the same structure as e-mail messages. They contain message headers and a multipart MIME body, in which certain parts must be present. The simple and compatible format of the MMS messages provides the technical possibility of deliv-ering MMS messages from the public Internet to the MMS enabled phones. The sender address in such messages should never be trusted. Subsequently, charging according to the sender of MMS messages should be restricted to cases where the sender address


67



Id:0900d805808c042b

can be trusted. For example, messages delivered from local content services are usually safe.

To use the 'MMS from' filters, a flow specification that matches the MMS messages and uses event-based charging must be present. If no matching flow specification exists for the MMS message, the Flexi ISN will not perform the 'from filter' checking. The 'MMS from' filters are only available for event-based flow specifications.

An 'MMS from' filter is a string that consists of three comma-separated parts:

• the sender address pattern, which acts as the selector. Wildcards ‘?’ and ‘*’ can be used. If the sender address pattern begins with the '!' character, the Flexi ISN responds with a forbidden return code to the sender.

• the charging class (1 – 2147483647, or -1) • the second charging class (1 – 2147483647, or -1)

The filter may not contain space characters. The value -1 in any of the charging class indicates a none action. For example, the MMS message is free if the charging classes have been set to –1.

If no second charging class is configured, the first charging class counts hits, or volume. If there is a second charging class, it must be for the volume and the first charging class must be for hits. The same charging class can be configured in both instances, in which case the volume and the hits will be reported to the same charging class.

When configuring the 'MMS from' filter to use a charging class it must be verified that the charging class in question has the correct metering method enabled.

If RADIUS prepaid charging is used, the same charging class cannot be used for both volume and hits because RADIUS prepaid charging only supports one metering mode for each charging class.

Up to 256 MMS sender filters can be defined. The filters are processed in the order they appear in the configuration. The order of the rules is important, since the first match with the sender address determines the action. If none of the defined filters match, the original rule, matching the inbound MMS, defines the charging action.

Example*@freeware.com,-1,-1 means that when the 'From:' header ends with the string @freeware.com, the inbound MMS is free for the subscriber instead of using a default MMS inbound rule.

5.8 Bearer chargingBearer charging refers to the charging of the whole PDP context. Bearer charging is possible based on G-CDRs, but the Flexi ISN makes it possible to use SA-CDRs also for bearer charging. In this way there is no need to use G-CDRs because all the required information is in the SA-CDR. For this purpose, the Flexi ISN uses rating group zero for reporting the total volume and duration of the PDP context. Rating group zero is used in both online and offline charging.

If online charging is used, the Flexi ISN must then request quota also for the whole PDP context. If there is no quota for the PDP context, no traffic can be passed through the Flexi ISN. It is possible to disable the use of the rating group zero. Note that the reported volume and time in rating group zero is in most cases also included in some other rating group.

68 DN04134609Issue 7-3 en


Id:0900d805808c042b


5.9 Special charging models

5.9.1 Mixing offline and online chargingThere are cases both offline and online charging interfaces are used:

• Post-paid with credit control. Here the online charging interface just provides control while the actual charging is done through the offline charging interface.

• Statistics. Usually if the online charging interface is used, the offline charging inter-face is used for gathering statistics. CDRs may even contain more metering data than the online charging interface.

5.9.2 Event chargingThe Flexi ISN supports event charging through hit-based metering. In this case, the Flexi ISN detects a defined event related to L7 traffic and records a hit. The following issues should be remembered in event charging when online charging is used:

• The DCCA interface in the Flexi ISN is optimized for the session-based model, where first quota is requested and then the use is reported (at least four messages need to be exchanged). The DCCA interface would become overloaded if each single event needed to be reported separately.

• The Flexi ISN may not buffer traffic. Default quota is used before the real quota has been received from the OCS. If for certain charging cases the fraud possibility is not acceptable, the charging of events must be implemented in the application function (AF), that is, the content provider. This limitation applies, for example, for MMS charging.

Offline charging does not have similar limitations, but has its own issues. The preferred charging model should be based on the rating group ID (charging class) and service ID. Sometimes this reporting granularity is not sufficient for the operator for the following purposes:

• Revenue sharing might require finer granularity. It is not feasible to define a unique service ID for each content provider if the number of content providers is high. For example, artist X should receive revenue only for the media in which the artist is per-forming.

• Rating may require that reporting is based on the accessed URL. Again the rationale is the same as in the previous case: it is not feasible to define hundreds of rating groups (and rules) for each possible rating alternative. For this reason, it is possible to report the configured (HTTP and WAP) URL, or the actual requested URL (RTSP) in the charging interfaces if the basic reporting granularity based on service ID and rating group is not sufficient.

• The operator will need to provide detailed service use history, if requested.

The Flexi ISN offers support for the above mentioned business cases. For RTSP traffic, it is possible to enable the sending of the RTSP URL in the online charging interfaces. That way the online charging system will know which media clip was actually accessed. For browsing traffic this approach is not feasible because even a single user interaction can mean access to multiple HTTP, or WAP URLs (for example, each figure shown in the browser will have its own URL). To avoid overloading the charging system, while still supporting a way to report the URL in charging interfaces, the Flexi ISN may send the configured URI of an L7 flow specification to the charging systems.


69



Id:0900d805808c042b

5.9.3 Revenue sharingCharging in the Flexi ISN concentrates on mobile subscribers. The Flexi ISN counts volumes, time and hits for each mobile subscriber. The information is passed to the charging system through online and offline charging interfaces. Based on the received information, the billing system eventually generates a bill for the post-paid users, or extracts money from the prepaid balance.

Although mobile subscriber charging is the main income for the operator, there are also other charging scenarios. An external service provider might implement some of the services the operator offers to his customers. If these services are used, the operator will still get the money from the mobile subscribers, but the operator should then share some part of the revenue with the service provider. This operation is called revenue sharing.

Revenue sharing is not a real-time activity. It can be implemented offline in the charging system based on the CDRs in the Flexi ISN produces. Revenue sharing requires that it is possible to differentiate traffic related to the external service providers from other traffic. Differentiated charging can group traffic flows based on the service identifier and charging class. Thus, revenue sharing does not require anything special from the Flexi ISN, because the Flexi ISN simply provides the means for implementing revenue sharing in the charging system.

5.9.4 Zero ratingZero rating refers to the use case where the actual charging is done outside the Flexi ISN, but the Flexi ISN needs to report the use to the charging system, so that the charging system can exclude the volume related to the special service from the basic volume. Zero rating is common, for example, in MMS charging where the actual MMS charging is done in the MMSC, but the Flexi ISN needs to exclude the MMS traffic volume from the other traffic. This way the MMS traffic can be handled as free traffic in the Flexi ISN. Depending on the charging class configuration, the Flexi ISN may omit reporting the volume or it may use a special rating group ID.

5.10 Charging concepts

5.10.1 Default quotaThe default quota, like quota in general, only applies to online charging. The Flexi ISN requests a quota when the service is first being used. Buffering user plane traffic is not feasible and dropping the traffic would greatly reduce the end user experience. Thus, the Flexi ISN uses the default quota before it has received a quota from the online charging system (OCS).

The default quota can be configured separately for each charging class. A separate default quota is also defined for the whole PDP context. A default quota is defined for all possible metering types: time, hits and volume.

5.10.2 Quota consumption timerIf time-based metering is enabled, the quota consumption timer (QCT) (also called the silence period) defines when the time-based metering is stopped for the traffic. If the

70 DN04134609Issue 7-3 en


Id:0900d805808c042b


value of QCT is t and there is no traffic for t seconds, the metering is stopped. Metering is restarted when new traffic is detected.

The QCT is configured for each charging class, or the OCS can define it.

5.10.3 Quota holding timerThe quota holding timer (QHT) defines when the dynamic flow should be released and when the unused quota related to the dynamic flow is no longer used in the Flexi ISN. If new traffic that uses the released quota is detected, the Flexi ISN must request quota from the online charging system.

The QHT is configured for each charging class, or the OCS can define it.

5.10.4 Non-permission timerThe non-permission timer (NPT) is used in online charging. If the OCS terminates the use of a service component, the NPT is started for the service. While the NPT is active, the service component cannot be used in that PDP context. The Flexi ISN will then block all traffic related to the service component. When the NPT has expired, the Flexi ISN will then again request quota from the OCS.

5.10.5 TariffsThe Flexi ISN supports the use of different tariffs. For example, during weekdays and office hours the price of services might be higher than during weekends. The support for tariffs requires that the Flexi ISN knows when the tariff change happens and the Flexi ISN is able to report the use before and after the tariff change in separate counters. It is also essential that the tariff change does not immediately cause any signalling towards charging systems to avoid overloading the online and offline charging interfaces.

When offline charging is used, the Flexi ISN configuration is used to define tariff change times. The tariff change will close the container in the charging record (CDR) so the use before and after the tariff change is reported in separate counters. Unless the CDR already has the maximum amount of containers, there is no reason to close the CDR when a tariff change happens and therefore send no signalling over the offline charging interface.

To prevent the Flexi ISN and the charging gateways from becoming overloaded at the time of a tariff change, the Flexi ISN handles tariff time changes for charging classes randomly within five minutes after a tariff time change has occurred. Therefore, there must be at least six minutes between two configured tariff time changes.

When online charging is used, the Flexi ISN gets the tariff change times from the OCS. Tariff changes are part of the DCCA protocol functionality. When the OCS defines the tariff change time, it will also define the quota after the tariff change. Separate counters are used in the DCCA to report use before and after the tariff change so there is no need to send any messages when the tariff change occurs.

5.10.6 WalletsWallets are a special case in charging. In a normal case, the mobile subscriber only has one charging account. Wallets provide the means to have multiple charging accounts for each mobile subscriber. Wallets are linked to services and can be used only along with differentiated charging. Figure 17 shows how the wallets are related to the services.


71



Id:0900d805808c042b

For one PDP session (one primary, or multiple secondary PDP contexts) four services are activated and Service A is charged according to Wallet 1, while the rest of the services are charged based on Wallet 2.

Figure 17 Wallets and services

Each wallet may have a different charging profile, and its value may be prepaid, post-paid, prepaid with credit card, or postpaid with credit control.

There are two ways to define the wallets:

1. The user profile. If all the wallets are using offline charging, the wallets must be defined in the user profile. However, if online charging is enabled in the PDP context, there is no need to define the wallets in the user profile, because then the OCS must always define the wallets.

2. The Diameter interface (DCCA). If the wallets have been defined in the user profile, the Flexi ISN passes the wallet information in the initial Credit-Control-Request message (CCR), and the OCS defines the final wallets in the Credit-Control-Answer message (CCA). Note that in this case, the wallet configuration in the user profile is used only as hint to the OCS. For example, if the OCS disables wallets, the wallets of the user profile will be ignored. The wallet configuration received from the OCS affects also the CDRs.

When using simultaneously both online charged wallets (that is, those that have the charging profile set to prepaid, prepaid with credit card, or postpaid with credit control) and offline charged wallets (postpaid), the following restriction must be noted. User profiles and flow specifications must be configured so that the same charging class is never associated with both online charged wallets and offline charged wallets. In other words, services that are linked with an online charged wallet are not allowed to share any charging classes with services that are linked with an offline charged wallet.

72 DN04134609Issue 7-3 en


Id:0900d805808c569d

Browsing

6 Browsing

6.1 WAP 1.xThe Wireless Application Protocol (WAP) is actually an architecture and a family of pro-tocols for cellular phones and other wireless terminals. One of its main goals is to provide access to the Internet content and advanced services for the wireless devices which have many limiting factors compared to desktop and laptop machines. The WAP Forum originally developed the WAP, but now the Open Mobile Alliance (OMA) is con-tinuing the work.

Figure 18 illustrates the WAP interaction model. It is very similar to the Hypertext Trans-mission Protocol (HTTP) interaction model. The main visible change is the new arrow for Push services. The WAP also supports the push interaction model, where the appli-cation server initiates the transaction. The WAP uses the URL similarly to the HTTP to uniquely identify the resources referred by the WAP requests. The WAP also supports proxies as in the HTTP.

Figure 18 WAP interaction model

WAP uses layered protocol architecture. It supports both the connectionless and con-nection-oriented mode of communication. There are two main releases of WAP: WAP 1.x and WAP 2.0. The supported protocols depend on the WAP version used. The L3 protocol used is the IP in the GPRS networks.

WAP uses more layers than normal IP protocol stacks. The Wireless Transaction Protocol (WTP) is used to implement simple transaction support over the connectionless L3 protocols. It is not needed if the connection-oriented L4 protocol is used.

The actual WAP transactions are handled either by HTTP, or by the Wireless Session Protocol (WSP). HTTP is not supported in WAP 1.x. The content accessed by HTTP, or WSP is defined by the wireless application environment. The old user equipment only supports the Wireless Markup Language (WML), but the new WAP 2.0 compliant models can also use HTML directly.


73


Browsing

Id:0900d805808c569d

6.2 HTTP and WAP 2.0The Hypertext Transmission Protocol (HTTP) is one of the most used Internet protocols.

Figure 19 shows the interaction model of the HTTP. The client Web browser sends an HTTP request to the HTTP server. The HTTP server analyzes the request. The main attribute of the HTTP request is the uniform resource locator (URL), which uniquely defines the resource requested by the client. In most cases the client only wants to get the content stored in the application server and the HTTP server returns the requested content in the HTTP response.

Figure 19 HTTP interaction model

In some cases, the client wants to send data to the application server, which is to be stored in the content repository. There are two ways to pass information to the applica-tion server:

• query stringThe URL may contain an additional string, which is not used to identify the requested resource. The query string can only be used when there is very little data to be passed to the application server.

• post methodHTTP supports many methods. The HTTP requests usually use the get method, but if the client wishes to send data to the HTTP server, the post method can be used instead.

In summary, the Flexi ISN supports the following HTTP functionalities:

• HTTP 1.0 and HTTP 1.1 requests • virtual hosts: several WWW applications share the same HTTP server and possibly

the same IP address; different host names are used to access the services • persistent connections: the same TCP connection is used for several HTTP

requests, for example, downloading an HTML document and related pictures; HTTP analysis handles charging correctly even if the documents have been configured to different charging classes

• charging for POST requests • charging for CONNECT requests • different content transfer encoding, for example, chunked encoding • pipelining is supported in basic analysis

74 DN04134609Issue 7-3 en


Id:0900d805808c569d

Browsing

HTTP is also used in WAP 2.0 so it will become the major user plane protocol in the mobile networks and the Flexi ISN.

The Flexi ISN supports the L7 analysis of the HTTP. First, an L4 flow specification must be created for the related L4 flows and HTTP analysis must be enabled for this flow specification. Then, one or more L7 flow specifications are linked to the L4 flow specifi-cation. The Flexi ISN supports both basic and proxy HTTP analysis (the differences between these two modes are described in Sections Basic HTTP and WAP analysis and Proxy HTTP and WAP analysis). Note that it is not possible to use both the basic and proxy mode for the same L4 flow.

6.3 Basic HTTP and WAP analysisThe following attributes are used in the L7 flow specifications for basic HTTP and WAP analysis:

• URLThe Flexi ISN can classify the HTTP traffic based on the URL used in the HTTP request. Wild cards can be used in the URL.

• uplink hit triggerThe Flexi ISN reports one uplink hit whenever the HTTP, or WAP method in the request message matches the configured uplink hit trigger. It is possible to define multiple uplink hit triggers, or use a configuration which produces a hit for all request messages.

• downlink hit triggerThe Flexi ISN reports one downlink hit whenever the HTTP or WAP status code in the response message matches with the configured downlink hit trigger. It is possible to define multiple downlink hit triggers, or use a configuration which produces a hit for all response messages.

When basic HTTP, or WAP analysis has found the matching L7 flow specification, the action is defined by the L7 service component. The following actions are supported in basic analysis:

• Charging is based on the configured charging classes. • It is possible to block traffic according to the configured action in the URI initiation

rule. The actions 'deny' and 'drop' cause the same action in basic analysis. • The URL of the L7 flow specification can be sent over charging interfaces depending

on the configuration. This makes it possible to know which L7 flow specification was actually detected in the analysis.

• Redirection configuration is used in WAP 1.x redirection (see Section Basic WAP 1.x redirection).

WAP version 2.0 uses HTTP as the transport protocol instead of the User Datagram Protocol (UDP)-based Wireless Session Protocol (WSP) and Wireless Transaction Protocol (WTP) found in previous versions of WAP. Similarly, MMS messages can be delivered by using HTTP. The HTTP analyzer handles these cases since the traffic appears as ordinary HTTP.

Static redirection configuration is used in HTTP/WAP2.0 redirection (see Section Con-figured redirection for WAP and HTTP traffic).

Volume metering is done in L7.


75


Browsing

Id:0900d805808c569d

6.3.1 Malformed HTTP traffic handlingIf the HTTP basic analyzer encounters some traffic, which cannot be processed as valid HTTP protocol traffic, the analyzer considers such traffic as malformed.

A special URI "http://malformed" can be used for matching malformed traffic for the basic HTTP analyzer. All the metering data for malformed traffic are reported with this URI, and the traffic will be matched to the corresponding URI if configured, that is, the first matching URI according to general URI matching rules - either "http://malformed" or "http://mal*", or "http://m*", or "*", which ever will be first encountered. If none matches found, the traffic will be dropped.

Once malformed traffic identified for some TCP connection, the analyzer is unable to recover this connection, that is, even if valid HTTP traffic will be sent in the same TCP connection, it will not be properly analyzed as HTTP traffic and reported as malformed. Most common causes of malformed traffic can be the following:

• a missing or incorrect Content-Length field in HTTP requests or responses • a malformed request or response • non-HTTP traffic matched to the HTTP flow (for example, some peer-to-peer client

protocol running on the TCP port 80)

g TCP signaling traffic (such as SYN, ACK, FIN packets) is not handled by the HTTP basic analyzer and cannot be reported as malformed even if it is.

6.4 Proxy HTTP and WAP analysisProxy HTTP and WAP analysis ignores the uplink and downlink hit trigger configuration. Proxy analysis does not differentiate between the uplink and downlink hits. When the HTTP, or WAP response indicates success, a hit is recorded. For HTTP, the response codes 200, 201 and 252 generate a hit. No hit is recorded for incomplete transactions.

Redirection of HTTP and WAP traffic is described in Section Redirection of browsing traffic.

When the volume is metered, the proxy analysis counts the volume in L4, while basic analysis supports metering of volume in L7. The volume charged by the WAP analysis subsystem is the WTP/WDP stream payload, containing all WAP headers. The WAP signalling traffic, that is, the acknowledgements and transaction aborts, can be either left out, or included in the chargeable data transfer volume. Charging for retransmitted packets is a configurable option. An HTTP stream can contain traffic for several charging classes if persistent connections are used. The traffic needed to establish the TCP con-nection is regarded as part of the first transaction and added to the charging class of the first request. Similarly, the traffic for taking down the TCP connection is considered part of the last request and added to the charging class of the last request.

Proxy analysis can add the subscriber’s IP address, MSISDN, MD5 MSISDN (scram-bled MSISDN), IMSI, MD5 IMSI (scrambled IMSI), the used APN, the prepaid status (in case of prepaid subscriber), IMEISV, the subscriber’s profile ID, billing type, zone ID and the Diameter session error flag as additional headers to all outgoing HTTP requests. The names of the headers are configurable. The HTTP servers can use the headers for identifying users. The L7 service component defines whether the additional headers are added.

76 DN04134609Issue 7-3 en


Id:0900d805808c569d

Browsing

If the HTTP proxy analysis detects that HTTP requests are pipelined, it places each pipelined HTTP request to a separate HTTP connection when communicating with the real HTTP server. The functionality is transparent to the user terminal.

MIME analysis is only supported in the proxy mode.

6.5 i-modeThe i-mode service, developed by NTT DoCoMo, uses the HTTP protocol for fetching content in HTML format from ordinary HTTP servers. The HTTP analysis module is able to charge for accessing i-mode content in layer 7 analysis, which means that all features of the HTTP analysis (for example, pricing according to the URLs and charging accord-ing to MIME types) are available for i-mode charging. The i-mode traffic generally uses port number 5080.

Because i-mode is simply an extension of normal HTTP, there is no need to define specific i-mode analysis. Instead, both basic and proxy HTTP analysis are able to perform i-mode analysis.

6.5.1 Basic i-mode analysisWhen basic HTTP analysis is enabled, the special result codes used in i-mode traffic need to be taken into account when downlink hit triggers are configured. The following table summarizes the special result codes used in i-mode.

6.5.2 Proxy i-mode analysisHTTP analysis in the proxy mode recognizes the result code used for successful e-mail message delivery in i-mode (252: i-mode mail accepted). When encountered, the result code 252 triggers the HTTP charging similarly to other status codes that indicate success (for example, 200 and 201).

Status code Meaning

251 Indicates that the mail has been obtained and that there is no accumulated mail left in the server.

252 Indicates that the server normally accepted the mail sent from the user equipment (UE).

255 Indicates that there is no accumulated mail left in the server.

451 Indicates that the mail sent from the UE was not accepted by the server, since there is no applicable mail address in the same domain as the user.

552 Indicates that the 'Mail sending request' sent from the UE was not accepted by the server due to a server error.

553 Indicates that the 'Message request' sent from the UE was not accepted by the server due to a server error.

554 Indicates that the request was not accepted due to an incomplete service order of the server.

561 Indicates that there is an unsent mail message due to an address error, etc. in sending broadcast mail.


77


Browsing

Id:0900d805808c569d

No special configuration is required for i-mode when proxy analysis is used.

6.6 Redirection of browsing traffic

6.6.1 Basic WAP 1.x redirectionOperators can use two, or more WAP gateways although there is only one WAP gateway setting in the user equipment. When using basic WAP analysis, the Flexi ISN can redirect WAP traffic using predefined rules. A new destination IP address can be inserted into the user WAP/MMS messages. Both the connectionless and connection-oriented modes are supported for WAP 1.x redirection.

The redirection is defined in the L7 service component. The configuration includes the IP address and port number of the new destination host.

6.6.2 Proxy HTTP redirectionWhen Proxy HTTP analysis is used, it is possible to redirect HTTP/WAP2 traffic to a con-figured IP address/port defined in the L7 service component. This address can be either another web server, or another proxy server. If it is a proxy server, it is possible to direct the traffic to another web server as well by using the URI rewriting configuration in the L7 service component. The functionality is transparent to the user equipment.

g When Proxy HTTP redirection is used, persistent connections are not supported.

Moreover, the URL path of the HTTP request can be rewritten by using the URI rewriting configuration in the L7 service component.

Note that the rewriting of the URL path, configured in the L7 service component, can be performed with, or without a configured redirection IP address.

Two additional configuration flags in the L7 service component define the needs for rewriting the HTTP host header and changing the HTTP request format. Their use facil-itates different redirection scenarios.

6.6.3 Configured redirection for WAP and HTTP trafficWhen proxy analysis is used, it is possible to redirect WAP, or HTTP traffic to a config-ured URL in the following cases:

• There is no quota • Access is denied

Note that when basic analysis is used, only the first case (“There is no quota”) is appli-cable. In addition to that, in either of these cases the HTTP redirection described in the Section Proxy HTTP redirection will not be performed if configured.

The first case is possible if online charging is used and the online charging system indi-cates that there is no quota for the traffic. The second case is triggered according to the L7 service component configuration. If the configured action for the traffic flow is 'deny', the related flows are redirected. The HTTP/WAP2 analyzer configuration in the Flexi ISN defines two redirection URLs for these cases: Payment Required URL and For-bidden URL. The error pages served from the redirection locations must provide expla-nations about the reason for denying access.

78 DN04134609Issue 7-3 en


Id:0900d805808c569d

Browsing

When basic analysis is used it is possible to redirect WAP, or HTTP traffic to a config-ured URL in the following case:

• There is no quota.

The HTTP/WAP2.0 configuration in the Flexi ISN defines the static redirection URL for the case Payment Required URL.

For both analyzers, proxy or basic, it is possible to include additional information when a WAP, or HTTP request is redirected. The additional information is passed in the query string part of the URL. The additional information can include, for example, the IMSI, or the originally requested URL. The redirection page can thus contain subscriber-specific information, or the content can be customized based on the originally accessed URL.

For the redirection to a Payment Required URL, when the subscriber runs out of quota, there are two options to retrieve this URL; from Voyager (Static redirection), or from the OCS through diameter interface (Dynamic redirection).

A Wireless Session Protocol (WSP) session between the user equipment (UE) and the Flexi ISN may correspond to multiple sessions between the Flexi ISN and various WAP gateways. However, a one-to-one relationship is the usual case. Because the Flexi ISN always uses the IP address and port number of the original destination host when com-municating with the UE, the UE will not be aware that the reply does not arrive from the original destination WAP gateway.

For WAP traffic, redirection is also possible in cases where the WAP gateway replies with a WSP REDIRECT message when the Flexi ISN attempts to establish the WSP session. In this case, the Flexi ISN attempts to connect to the WAP gateway whose address was received from the original WAP gateway.


79


Messaging

Id:0900d805808160d2

7 Messaging

7.1 MMSThe Multimedia Messaging Service (MMS) is defined as a person-to-person and appli-cation-to-person standardized messaging service, providing the ability to send and receive messages using a combination of text, audio, graphics, image, animation, and video, between User Equipment (UE) as well as between the UE and content servers. In other words, the MMS extends the basic SMS, which is purely text-based messaging.

Deploying an MMS system within a GPRS network is very straightforward. For a basic system, all that is required is an MMS Center (MMSC). The basic functionality can later be expanded to services such as smart e-mail push support and voice call termination.

Flexi ISN supports MMS traffic analysis for MMS over WAP 1.x and WAP 2.0 (HTTP). Both the basic and proxy modes are supported. The mode is selected in the L4 flow specification, where the appropriate L7 analysis is selected and enabled. MMS analysis is enabled whenever either WAP 1.x, or HTTP analysis is configured in the L4 flow spec-ification. The choice between basic and proxy MMS analysis is made based on whether basic, or proxy WAP/HTTP analysis is selected in the L4 flow specification.

If no special MMS analysis is required for MMS traffic, L4 analysis is recommended. The following conditions need to be true if no L7 analysis for MMS traffic is used:

• MMS traffic can be differentiated from other traffic based on L4 attributes • no need for hit-based charging • no need for MIME-based charging • no need for charging based on recipients or senders • no need to modify the URL in MMS messages • no need to redirect MMS traffic in any circumstances

If no MMS differentiation is required at all, there is no need to perform MMS analysis on any level.

7.2 Basic MMS analysisWhen basic MMS analysis is used, it is recommended that a separate L4 flow is used for MMS traffic. The selection between MMS analysis and WAP/HTTP analysis is based on the configured hit triggers in the L7 flow specifications.

The MMS analysis is mainly based on the uplink hit trigger of the L7 flow specification. Based on the value used in the uplink hit trigger, the following MMS messaging cases can be differentiated:

• sending an MMS message • receiving an MMS message • receiving an uncompressed MMS message from a certain sender • control messaging related to the MMS

It is also possible to block the sending, or receiving of MMS messages based on the con-figured uplink hit trigger. For more information about hit trigger configuration, see Service Configuration in Nokia Siemens Networks in Flexi ISN.

In WAP 1.x it is possible to redirect MMS messages to another MMSC. An MMS message (sent, or received) initiated by the user equipment with settings for MMSC A

80 DN04134609Issue 7-3 en


Id:0900d805808160d2

Messaging

can be redirected to MMSC B (configured inside the Rewrite URI field in the service component). To enable this redirection, the message should be matched to an L7 flow according to its URI and uplink hit trigger. If, for example, you want all MMS messages to MMSC A to be redirected to the new MMSC, you can configure the following in the URI field: http://<MMSC_A_IP>*. MMSC redirection can take place together with WAP proxy redirection (configured in the Redirect Address and Redirect Port fields).

For instructions, see Section Defining WAP MMSC redirection in Service configuration in Flexi ISN.

Time and volume metering is also supported according to the charging class configura-tion in the L7 service component linked to the L7 flow specification. Basic MMS analysis does not support charging of MMS according to the recipients of the sent MMS message.

g Charging may be incorrect when the MMS is compressed.

Otherwise, the analysis of MMS traffic functions similarly to the basic HTTP and WAP analysis.

7.3 Proxy MMS analysisThe Proxy MMS analysis makes it possible to use MMS analysis and WAP/HTTP analysis for the same L4 traffic flow. The global configuration defines some basic prop-erties for MMS analysis in the proxy mode. One basic difference between the basic and proxy mode is the need to configure the MMSC domain names and IP addresses. This configuration is used to determine whether the MMS analysis, or WAP/HTTP analysis should be used. L7 traffic contains the URI. If the URI contains the domain name, or the IP address of one of the configured MMSCs, the traffic is analyzed as MMS traffic.

Sometimes it is possible to determine that the traffic is an MMS, even if the destination IP address is not one of the configured MMSC addresses. For this purpose, the Flexi ISN configuration defines whether MMS traffic to an unknown MMSC is allowed, or not.

Proxy MMS analysis shares several functionalities with proxy WAP/HTTP analysis:

• Hit trigger configuration is ignored. Hits are generated according to a fixed policy. A hit is generated when the sending, or receiving of an MMS message has been suc-cessful.

• Additional hits may be generated based on the detected MIME types in the MMS payload.

• Volume and time metering works similarly to WAP and HTTP analysis and volume metering counts L3 volumes.

• The 'deny' action redirects MMS traffic to the configured URL. • If there is no quota, the traffic is redirected to the configured URL. • With proxy HTTP analysis the MMS traffic can be redirected to another WAP

gateway, or to another MMSC, or both, according to the configuration in the L7 service component. This redirection functionality is the same as the one described in Section Proxy HTTP redirection.

Also, there are additional differences between basic and proxy MMS analysis. The con-figured URI in the L7 flow specification defines how MMS traffic is charged, while in basic L7 analysis the URI defines the URI used in MMS messages. In other words, there is no need to configure the actual URI used in MMS messages when proxy analysis is


81


Messaging

Id:0900d805808160d2

done. Based on the configured URI in the L7 flow specification it is possible to differen-tiate between the following MMS messaging scenarios:

• sending an MMS message • receiving an MMS message • control messaging related to the MMS

7.4 MMS message charging according to the recipients of the messageMMS messages can be charged according to the recipients of the message. This func-tionality is only supported in the proxy mode. Based on the global configuration the func-tionality is enabled, or disabled whenever the MMS analysis in the proxy mode is used.

The recipient addresses in MMS messages can be compared to IEEE 10003.2 regular expression patterns. The regular expression patterns are associated to multiplication factors. When a recipient address matches the pattern, the multiplication factor is used to multiply the number of hits that will be added to the charging class counter. The charging class is always determined according to the service component that matched the MMS message.

g Using MMS charging according to the recipients and using the multiplication factors with recipient address patterns may lead to unexpected charging results. The number of hits charged from subscribers may become large if a message is delivered to several recip-ients.

Enabling this feature should always be carefully considered.

7.5 SMTP analysisThe Flexi ISN supports analysis of Simple Mail Transfer Protocol (SMTP) on layer 7. SMTP analysis is supported only in the proxy mode.

SMTP analysis can be used for the charging of mail sending. Hit-based charging for e-mail submission takes place if the server has received the complete message and responded with code 250, that indicates successful reception of the mail. One hit is always one successful mail sending. No SMTP-specific configuration is required because the hit generation policy is fixed.

It is possible that sometimes mail delivery fails, even if a hit has been recorded. The SMTP protocol requires the server to write the message to persistent storage before issuing the reply code indicating success. Mail delivery may still fail later on, but that cannot be noticed in the conversation between the e-mail client and server. Thus, it is impossible for the Flexi ISN to detect this failure case.

SMTP L7 analysis is used for analyzing SMTP requests and responses for hit-based charging and hit + volume-based charging. No other charging type is supported. L4 analysis should be used if no hit-based charging is required. In that case, the corre-sponding SMTP traffic can be identified according to the L4 attributes.

82 DN04134609Issue 7-3 en


Id:0900d805808d42a7

Streaming

8 Streaming

8.1 Overview of RTSPThe Real-Time Streaming Protocol (RTSP) contains commands for negotiating the transport protocol, port numbers and data encoding, as well as starting, pausing and stopping the stream. A separate data path is always used for the multimedia payload. The RTSP specification does not specify any protocol for the data stream. Instead, the client and the server can choose any protocol that they both understand. For example, the products by Real Networks use a proprietary protocol called Reliable Data Protocol (RDP), while other applications may use Real-Time Transport Protocol (RTP) standard-ized by IETF. The Flexi ISN can analyze and charge the use of streaming protocol, including RealAudio and Real Video, if RTSP is used to control the stream. Figure 20 illustrates a multimedia transfer session, where the RTP is used for transferring the data stream.

Figure 20 Multimedia transfer session with the RTP transferring the data stream

Streaming (RTSP and RTP) charging can be based on either data volume, or playing time. Hit-based charging, that is, a fixed fee for starting the playback of an audio/video stream, is also available. Combinations of the above are supported as well.

It is also possible to configure RTSP analysis only in L4, but in that case some of the functionalities are not supported. When L7 RTSP analysis is enabled in the Flexi ISN, the following additional functionalities are enabled:

• hit generation based on the analysis of the RTSP traffic • time metering based on the analysis of the PLAY, PAUSE and STOP commands • creation of dynamic flows based on the analysis of the RTSP control connection

Note that it is not possible to count the volume of the data connection without the L7 analysis because the ports used in the data connection are negotiated dynamically over RTSP. Analyzing only RTSP control connections would provide very limited charging capabilities because the actual content stream would be transferred outside the scope of the analysis. The actual amount of data would remain unknown.

Invoking RTSP analysis is based on the L4 analysis and the configured L7 analysis mode in the matching L4 flow specification. The Internet Assigned Numbers Authority (IANA) has allocated port 554 for RTSP, but it is possible to configure any port number for triggering the L7 analysis for RTSP traffic.


83


Streaming

Id:0900d805808d42a7

RTSP over Secure Sockets Layer (RTSPS) is not supported because the SSL provides strong cryptographic protection for the control channel, preventing detailed analysis. RTSP with a UDP control channel (RTSPU) is not supported either.

When RTSP analysis is used, the RTSP URL in the RTSP request can be added to the Diameter Credit Control Application (DCCA) request in online charging. This functional-ity is enabled in the L7 service component. It makes it possible to inform the online charging system which streaming clip has been actually played in the user equipment.

The Flexi ISN supports basic and proxy modes for RTSP analysis. Sections Basic RTSP analysis and Proxy RTSP analysis summarize the differences between these two modes.

8.2 Basic RTSP analysisBasic RTSP analysis is based on sniffing the RTSP traffic while it passes through the Flexi ISN. The URI in L7 flow specification is used to find the matching streaming RTSP URI. Wild cards can be used in the URI. The RTSP clients can add track information at the end of RTSP URIs. Thus, it is necessary to add an asterisk at the end of the config-ured RTSP URLs.

When a matching L7 flow specification has been found, the Flexi ISN determines which of the linked L7 service components is selected. Then, it will define the action (policy) for the analyzed RTSP traffic. If traffic is allowed to pass, charging is done according to the configured charging classes in the L7 service component. It is possible to meter hits, volume, time, and all combinations of these metering types.

The metering of hits is based on the uplink and downlink hit triggers in the L7 flow spec-ification. The uplink hit trigger defines which RTSP methods generate an uplink hit. The downlink hit trigger defines which RTSP response code generates a downlink hit.

The data volume for which charging takes place consists of the sum of all data stream L7 volumes transferred during an RTSP session. That is,

• the volume of data transferred in the control channel • the volume of data transferred in the multimedia streams

The metering of time is based on the analysis of the PLAY, PAUSE and TEARDOWN commands. The counting of time starts when the PLAY command is detected. The time metering stops by the PAUSE and TEARDOWN commands, as well as on data stream termination, for example, by TCP RST in case of the TCP-based data stream. Note that the quota consumption timer is always added to the reported time when the counting of time is stopped. Because the Flexi ISN measures the playing time of a RTSP stream according to the data delivered between the client and the server, the playing time of a RTSP stream is usually a little different than the reported duration of the content item in the user equipment. Many factors, such as network delays, buffering in the user equip-ment, rewinding and packet loss, contribute to the difference.

8.3 Proxy RTSP analysisThe proxy mode for RTSP supports some additional functionality. It uses the configura-tion slightly differently than the basic RTSP analysis.

Selecting the L7 flow specification and L7 service components works similarly in the basic and the proxy mode. If the action in the L7 service component is 'deny', the RTSP

84 DN04134609Issue 7-3 en


Id:0900d805808d42a7

Streaming

failure code is returned to the RTSP client in the user equipment, while the 'drop' action silently drops all RTSP traffic.

The Flexi ISN does not support multicast RTSP data streams. If the client sends a proposal for a multicast transport, the proxy RTSP analysis rejects it and causes an alternative protocol to be used. According to the RTSP protocol specification (RFC 2326), the default protocol to be chosen in the absence of the transport header is usually the User Datagram Protocol (UDP) with an ordinary unicast destination address. For more information, see RFC 2326.

Hit generation in the proxy mode is based on a fixed policy, which is not configurable. The uplink and downlink hit triggers in the L7 flow specification are not used in the proxy mode. A hit is generated in the proxy mode RTSP analysis when the RTSP server responds with a successful response code to the PLAY command. The RTSP protocol allows the user to stop the playback temporarily by issuing the PAUSE command. The PLAY command resumes the playback of a multimedia stream. The subsequent PLAY command for the same resource in the same RTSP session does not generate a new hit.

g When a hit is generated it cannot be guaranteed that the subscriber has actually received and viewed the whole streaming clip. This limitation cannot be removed by using the basic mode, because the basic mode simply offers more configurability for hit generation.

The metering of time and volume, functions similarly to the basic analysis, except that in volume metering the L3 volumes are counted.

8.4 Redirection of streaming trafficReal-Time Streaming Protocol (RTSP) redirection is supported only if the proxy mode is selected for RTSP analysis. The purpose of RTSP redirection is to redirect RTSP traffic to an external RTSP proxy server. An RTSP proxy can be used to reduce the bandwidth required from external streaming content sources or, alternatively, to function as an application-protocol-level gateway for RTSP traffic. The purpose of RTSP redirection is not load balancing.

Redirection of RTSP traffic is enabled based on the used Gi connection. The RTSP con-figuration defines the access points where redirection is enabled. If packets are for-warded to the Gi connection defined by an access point where redirection is enabled, then the proxy RTSP analysis will redirect the traffic to the configured RTSP proxy. One RTSP proxy is supported for redirection.


85


PoC analysis

Id:0900d805806f306f

9 PoC analysisThe Flexi ISN also supports analysis of the Push to talk over Cellular (PoC) traffic. The PoC service provides one-to-one and one-to-many voice communication services in a GPRS/EDGE/3G data network. The PoC service is always available whenever the sub-scriber is registered to the PoC server; the subscriber can send messages to a PoC group, or to another subscriber by pushing the Talk button in the handset.

PoC is a half-duplex voice service, which means that a subscriber cannot receive data while transmitting PoC traffic. Additionally, only one subscriber can be talking in a PoC group at a time. The PoC service consists of two data flows. The Session Initiation Protocol (SIP) used when the user connects to the PoC server and joins, or leaves PoC groups. The voice payload is transmitted to a different channel. The Flexi ISN does not analyze the SIP protocol, only the voice payload is needed for charging the PoC traffic.

PoC analysis supports the functions presented in Nokia Siemens Networks PoC versions 1.0, 1.5, and 2.0 (OMA), including analyzing the standards-based RTP protocol for transferring the PoC payload traffic. The Flexi ISN performs PoC analysis by inspect-ing the contents of the PoC packet stream. The packets that carry PoC traffic pass through the Flexi ISN host unaltered; the Flexi ISN does not terminate the PoC packet stream (as with Layer 7 analysis for TCP-based protocols), or redirect the packets to other destinations. The Flexi ISN may discard the packets if a prepaid subscriber has run out of quota, or if the rules deny access to the PoC service.

The data volume and time and the hit-based charging models can be used for PoC traffic. Additionally, upstream (sending) and downstream (receiving) PoC traffic can be billed into separate charging classes.

Hit-based charging of the PoC service is based on detecting PoC traffic bursts from the packets transmitted between the terminal and the PoC server. A PoC traffic burst begins when the subscriber presses the Talk button in the mobile phone and ends when the subscriber releases the Talk button. The Flexi ISN detects the talk burst according to the control packets located at the start and at the end of the burst. If the start packet has been lost for some reason and the Flexi ISN detects Streaming Transport Protocol (STP), or RTP packets carrying PoC payload, Flexi ISN assumes that a PoC traffic burst is ongoing.

A minimum charging time can be defined for time-based PoC charging. When set, the charging class counter will be incremented by at least the configured minimum value whenever a PoC traffic burst is detected. The minimum time applies to downstream and upstream traffic similarly.

The control messages enclosing PoC traffic bursts can be left out, or included in the chargeable traffic volume when using volume-based charging. In Nokia Siemens Networks PoC 1.x, different prices can be applied to one-to-one and one-to-many (that is, group) PoC traffic. One-to-one PoC traffic uses a specific port number in the PoC server, whereas traffic to PoC groups is distributed over a range of ports. This property of the protocol allows using separate rules for one-to-one and one-to-many PoC traffic.

In PoC 2.0 (OMA) differentiated charging for one-to-many (group call) is not supported.

86 DN04134609Issue 7-3 en


Id:0900d805806f3072

FTP analysis

10 FTP analysisThe File Transfer Protocol (FTP) is specified in IETF standard RFC 959. As the name of the protocol implies, its purposeis to define the protocol for transferring files between nodes. The Flexi ISN analyzes FTP traffic between the user equipment and file servers, and keeps track of the FTP sessions. An FTP session consists of two connections:

• a control connection, used to invoke commands • a data connection, used for actual file transfer

The Flexi ISN supports both the active and passive FTP modes. In the active mode the file server initiates the data connection, while in the passive mode the client (user equip-ment) initiates the data connection. The client and server may negotiate the port numbers used for data connection. The FTP analysis in the Flexi ISN takes care of dynamically creating the flow for the data connection.

The FTP analysis in the Flexi ISN is implemented in a transparent proxy. The Flexi ISN does not support FTP analysis in the basic mode. See Sections Proxy L7 analysis and Basic versus proxy analysis for more information about the proxy analysis mode.

Charging of FTP traffic is based on both the control and data connections. The FTP analysis in the Flexi ISN inspects the control connection and creates dynamic rules for capturing the data transfer connections. Both the control and data connections charge the traffic according to the same flow specification and service component.

The supported charging models with FTP services are:

• hit, successful sending, or receiving a file • volume, layer 3 IP traffic related to flow • time • hit and volume • time and volume

The FTP analysis in the Flexi ISN generates hits, based on a fixed policy. This means that the hit triggers in the L7 flow specification are not used. The FTP analysis generates a hit when a certain FTP command is detected in the control connection and the related transaction has been completed successfully. Note that the commands used in the FTP client application are translated into FTP commands. The GET and MGET commands are translated into the RETR command in the control connection, while the PUT and MPUT commands are translated into the STOR, STOU, or APPE commands. The GET and PUT commands generate one hit. The MGET and MPUT commands generate one, or more hits, depending on the number of transferred files. A hit is reported only when the file server sends the 'Data Transfer Complete' reply code (226).

Time-based charging starts time counting when a matching L7 flow specification has been found. The quota consumption timer (also called the silence period) defines when the time metering is stopped (see Section Time-based metering). Note that if '*' is used in the L7 flow specification, all FTP traffic is considered in the time metering so the counting of time is not stopped unless the FTP traffic stops completely.

The data volume for which charging takes place consists of the sum of all transferred data: the volume of data transferred on the control channel and the volume of data trans-ferred on the data connections. It is not possible to meter the data and control connec-tion traffic to separate counters. The data volume for the FTP data connections is always counted at Layer 3. That is, IP retransmissions and datagram headers are a part of the data volume.


87


FTP analysis

Id:0900d805806f3072

Hit metering can be combined with time and volume metering. If there is no hit (Data Transfer Complete) the volume, or time, or both will still be counted. In other words, the volume and time metering does not take into account the success of a file transfer.

The URI in the L7 flow specification defines the matching file names for the flow speci-fication. The URI cannot contain a directory path. This restriction is caused by the FTP protocol (for more information, see RFC 959) when transferring a file from and to a direc-tory and consists of the steps:

1. Changing the working directory to the location of the file (the CWD command in the FTP protocol).

2. Transferring the file (the RETR/STOR/STOU/APPE commands).

File name comparison takes place in step 2. Thus, it is not possible to define an FTP rule that applies to a specific directory, which is the usual practice for the HTTP.

If the 'deny' action is defined in the service component, the Flexi ISN will indicate a failure in the reply code. If the 'drop' action is defined in the service component, the Flexi ISN will silently drop all traffic without counting the volume, hits, or time.

Redirection is not supported for FTP.

88 DN04134609Issue 7-3 en


Id:0900d805808c569b

Abbreviations

11 Abbreviations2G 2nd generation mobile communications

3G 3rd generation mobile communications

3GPP 3rd Generation Partnership Project

AP Access Point

APN Access Point Name

ASN.1 Abstract Syntax Notation One

CCA Credit-Control-Answer message

CCR Credit-Control-Request message

CDR Charging Data Record

CG Charging Gateway

DCCA Diameter Credit Control Application

DNS Domain Name Server

G-CDR GGSN Charging Record

GERAN GSM/EDGE Radio Access Network

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GW Gateway

HLR Home Location Register

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IETF The Internet Engineering Task Force

IMAP4 Internet Message Access Protocol, version 4

IMEI International Mobile Equipment Identity

IMEISV IMEI Software Version

IMS IP Multimedia System

IMSI International Mobile Subscriber Identity

ISN Intelligent Service Node

L2TP Layer 2 Tunnelling Protocol

L3 Layer 3 (network layer)

L4 Layer 4 (transport layer)

L7 Layer 7 (application layer)

LDAP Lightweight Directory Access Protocol

MIME Multipurpose Internet Mail Extension

MMS Multimedia Messaging Service

MSISDN Mobile Subscriber International ISDN Number

MSNP Mobile Status Notification Protocol

NAS Network Access Server


89


Abbreviations

Id:0900d805808c569b

NAT Network Address Translation

NPM Nokia Siemens Networks Profile Manager

NPS Nokia Siemens Networks Profile Server

OCS Online Charging System

OMA Open Mobile Alliance

OSC Online Service Controller

OSCAR Open System for Communication in Real Time

PAP Push Access Protocol

PCRF Policy and Charging Rules Function

PCS Policy Control Server

PLMN Public Land Mobile Network

PoC Push to talk Over Cellular

POP3 Post Office Protocol, version 3

PPG Push Proxy Gateway

QCT Quota Consumption Timer

QHT Quota Holding Timer

QoS Quality of Service

RADIUS Remote Authentication Dial-in User Service

RTCP Real-Time Transport Control Protocol

RTP Real-time Transport Protocol

RTSP Real-Time Streaming Protocol

RTSPS RTSP over SSL

RTSPU RTSP with a UDP control channel

RTVS Real-time Video Sharing

SA Service Awareness

SA-CDR Service-Aware CDR

SIP Session Initiation Protocol

SGSN Serving GPRS Support Node

SMTP Simple Mail Transfer Protocol

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLV Type-Length-Value coding

TPF Traffic Plane Function

TREC Treatment Class

UDP User Datagram Protocol

UE Use Equipment

URI Uniform Resource Identifier

URL Uniform Resource Locator

UTRAN UMTS Terrestrial Radio Access Network

90 DN04134609Issue 7-3 en


Id:0900d805808c569b

Abbreviations

WAP Wireless Application Protocol

WDP Wireless Datagram Protocol

WLAN Wireless Local Area Network

WML Wireless Markup Language

WSP Wireless Session Protocol

WTP Wireless Transaction Protocol

XMPP Extensible Messaging and Presence Protocol

YMSG Yahoo! Messenger Protocol

Documents

Service Awareness Flexi ISN