Archive for August 27th, 2010

27
Aug

4G to IMS call flow – Register to IMS – part 3

   Posted by: cristina_crow    in technical

This is a continuation of the 4G – IMS topic I’ve started a while back.

Still, before continuing the IMS registration started in http://www.imacandi.net/windancer/2010/08/26/4g-to-ims-call-flow-register-to-ims.html

I would like to show a preview of the Specs describing this fancy IMS thinggie.

[This information is not structured by me, but it was on tech-invite, before they decided to put a price on all that information.]

The General aspects:

3GPP TS 22.228 Service Requirements for the IP Multimedia Core Network (IM CN) Subsystem – Stage 1
3GPP TS 23.228 IP Multimedia Subsystem (IMS) – Stage 2
Registration:
RFC 3327 SIP “Path” Extension Header Field for Registering Non-Adjacent Contacts
RFC 3608 SIP Extension Header Field for Service Route Discovery during Registration
Diameter:
3GPP TS 29.109 GAA – Zh and Zn Interfaces based on the Diameter protocol – Stage 3
3GPP TS 29.229 Cx and Dx interfaces based on the Diameter protocol – Protocol Details
3GPP TS 29.230 Diameter Applications – 3GPP Specific Codes and Identifiers
3GPP TS 29.329 Sh Interface based on the Diameter protocol – Protocol Details
3GPP TS 32.299 Charging Management – Diameter Charging Applications
RFC 3588 Diameter Base Protocol
RFC 3589 Diameter Command Codes for 3GPP Release 5
RFC 4740 Diameter Session Initiation Protocol (SIP) Application
Identification:
3GPP TS 23.228 IP Multimedia Subsystem (IMS) – Stage 2
3GPP TS 29.229 Cx and Dx interfaces based on the Diameter protocol – Protocol Details
RFC 4282 The Network Access Identifier
Policy:
3GPP TS 23.203 Policy and Charging Control Architecture
3GPP TS 29.207 Policy Control over Go Interface
3GPP TS 29.208 End-to-end Quality of Service (QoS) Signalling Flows
3GPP TS 29.209 Policy control over Gq Interface
Charging:
3GPP TS 22.115 Service Aspects – Charging and Billing
3GPP TS 32.240 Charging Architecture and Principles
3GPP TS 32.260 IP Multimedia Subsystem (IMS) Charging
3GPP TS 23.125 Overall high level functionality and architecture impacts of flow based charging – Stage 2
3GPP TS 23.203 Policy and Charging Control Architecture
3GPP TS 29.210 Charging Rule Provisioning over Gx Interface
3GPP TS 29.211 Rx Interface and Rx/Gx Signalling Flows
3GPP TS 23.203 Policy and Charging Control Architecture
3GPP TS 32.295 Charging Data Record (CDR) Transfer
3GPP TS 32.296 Online Charging System (OCS): Applications and Interfaces
3GPP TS 32.297 Charging Data Record (CDR) File Format and Transfer
3GPP TS 32.298 Charging Data Record (CDR) Parameter Description
3GPP TS 32.299 Diameter Charging Applications
Security:
3GPP 33-series 3GPP Specifications related to Security
QoS:
3GPP TS 23.107 Quality of Service (QoS) Concept and Architecture
3GPP TS 23.207 End-to-end Quality of Service (QoS) Concept and Architecture
3GPP TS 29.208 End-to-end Quality of Service (QoS) Signalling Flows
OSA:
3GPP TS 22.127 Service Requirement for the Open Service Access (OSA) – Stage 1
3GPP TS 23.198 Open Service Access (OSA) – Stage 2
3GPP TS 29.198 29.198 series: Open Service Access (OSA) API
3GPP TS 29.199 29.199 series: OSA Parlay X Web Services
CAMEL:
3GPP TS 22.078 CAMEL – Service description – Stage 1
3GPP TS 23.078 CAMEL Phase 4 – Stage 2
3GPP TS 23.278 CAMEL Phase 4 – Stage 2 – IM CN Interworking
3GPP TS 29.078 CAMEL Phase X – CAMEL Application Part (CAP) specification
3GPP TS 29.278 CAMEL Phase 4 – CAP specification for IP Multimedia Subsystems (IMS)
3GPP TS 29.002 Mobile Application Part (MAP) specification
WLAN Access:
3GPP TS 22.234 Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking
3GPP TS 23.234 3GPP System to WLAN Interworking – System Description
3GPP TS 24.234 WLAN User Equipment (WLAN UE) to Network Protocols – Stage 3
3GPP TS 29.161 Interworking between the PLMN supporting Packet based Services with WLAN Access and PDNs
3GPP TS 29.234 3GPP System to WLAN Interworking – Stage 3
3GPP TS 32.252 WLAN Charging
3GPP TS 33.234 WLAN Interworking Security
CSICS: Circuit Switched IMS Combinational Services:
3GPP TS 22.279 Combined CS and IMS Sessions – Stage 1
3GPP TS 23.279 Combining Circuit Switched (CS) and IMS Services – Stage 2
3GPP TS 24.279 Combining Circuit Switched (CS) and IMS Services – Stage 3
Presence:
3GPP TS 22.141 Presence Service – Stage 1 – Requirements
3GPP TS 23.141 Presence Service – Stage 2 – Architecture and functional description
3GPP TS 24.141 Presence service using the IP Multimedia (IM) Core Network (CN) subsystem – Stage 3
3GPP TS 26.141 IMS Messaging and Presence – Media formats and codecs
3GPP TS 33.141 Presence service – Security OMA Presence Simple OMA Presence Simple V1.0.1 Approved Enabler
PoC: Push-to-talk over Cellular:
3GPP TR 23.979 Push-to-talk over Cellular (PoC) Services – Stage 2
3GPP TS 32.272 Push-to-talk over Cellular (PoC) charging
And now, let’s get down to business.

Tags: , , , , , , , , , , , , , , , , ,

27
Aug

4G to IMS call flow – Register to IMS – part 2

   Posted by: cristina_crow    in technical

As I was describing in the previous episode - 4G to IMS call flow – Register to IMS – part 1 - the IP-CAN Session Establishment is scheduled for today.

The procedure of IP-CAN (Connectivity Access Network) establishment is described in TS 23.203.

Basically, the IP-CAN is the IP address that the User Equipment gets:

- either during Initial Attach

- or at a Dedicated Bearer creation

that connects that UE to the IMS APN. There are multiple ways of getting this IP address, ways varying from DHCP/DHCPv6, PPP and so on. With regards to IMS, the IP-CAN is given by the PGW, following the PCC rules from its local PCRF.

But, before displaying the actual IP-CAN Session Establishment, let’s take a look at the functional entities and the architectures involved.

The possible scenarios when talking about PCC (Policy and Charging Control) functionality, presented in TS 23.203. I have just copied the architecture pictures. The functional entities are described separately in the same TS 23.203 spec – section 6.2. Functional Entities. I will just underline, where the case requires, which entity from this “PCC Reference Architecture” matches which entity on the 4G architecture.

Before, let’s clarify a few things about these 3 funky pictures:

The acronyms:

HPLMN == Home Public Land Mobile Network

VPLMN == Visited Public Land Mobile Network (the user is in roaming)

SPR == Subscription Profile Repository

TS 23.203 – section 6.2.4 – SPR :

The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and IP‑CAN bearer level PCC rules by the PCRF. The SPR may be combined with or distributed across other databases in the operator’s network, but those functional elements and their requirements for the SPR are out of scope of this document.

** The SPR is connected to the PCRF via the Sp interface.

AF == Application Function

TS 23.203 – section 6.2.3 – AF:

The Application Function (AF) is an element offering applications that require dynamic policy and/or charging control over the IP‑CAN user plane behaviour. The AF shall communicate with the PCRF to transfer dynamic session information, required for PCRF decisions as well as to receive IP‑CAN specific information and notifications about IP‑CAN bearer level events. One example of an AF is the P‑CSCF of the IM CN subsystem.

** The AF is connected to the PCRF via the Rx interface.

OCS == Online Charging System

- The OCS is described in TS 32.240. In the PCC architecture we are only interested in its component called Service Data Flow Based Credit Control - its main purpose being to perform online credit control functions.

** The OCS is connected to the PCEF via the Gy interface.

PCRF == Policy Control and Charging Rules Function

TS 23.203 – section 6.2.1 PCRF:

The PCRF encompasses policy control decision and flow based charging control functionalities.

The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF.

The PCRF shall apply the security procedures, as required by the operator, before accepting service information from the AF.

…………….

Here we are talking about 2 PCRF entities:

a) there is only one PCRF involved in the first case, when the UE is NOT in roaming; this is the local/home PCRF

b) in the home routed access and local breakout scenarios there is on one hand the V-PCRF (visited) – the PCRF entity from the visited network and on the other hand the H-PCRF (home) – the PCRF entity from the home network

** The PCRF is connected to the:

- AF via the Rx interface

- SPR via the Sp interface

- BBERF via the Gxx interface

- PCEF via the Gx interface

- H-PCRF and V-PCRF are connected via the S9 interface

BBERF == Bearer Binding and Even Reporting Function

TS 23.203 – section 6.2.7 BBERF:

The BBERF includes the following functionalities:

-     Bearer binding.

-     Uplink bearer binding verification.

-     Event reporting to the PCRF.

-     Sending or receiving IP‑CAN-specific parameters, to or from the PCRF.

* Note: As far as I understand, and in order to somehow “map” the names of the “PCC” entities to the names of the “EPC” entities I’ve first learned about, I believe this BBERF role is actually played by the SGW as we know it from the EPC terminology. Please correct me if I’ve got this wrong.

CORRECTION (further reading on TS 23.203): In the GTP-based 3GPP access network the BBERF entity does NOT apply.

** The BBERF is connected to the PCRF via the Gxx interface.

PCEF == Policy and Charging Enforcement Function

TS 23.203 – section 6.2.2 PCEF:

The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities.

This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case). It provides service data flow detection, user plane traffic handling, triggering control plane session management (where the IP‑CAN permits), QoS handling, and service data flow measurement as well as online and offline charging interactions.

………………

*Note: The EPC entity assuming the role of the PCEF in the PCC Architecture is the PGW.

** The PCEF is connected to the:

- PCRF via the Gx interface

- OCS via the Gy interface

- OFCS via the Gz interface

OFCS == Offline Charging System

TS 23.203 – section 6.2.6 OFCS:

The Offline Charging System is specified in TS 32.240 [3].

There may be several OFCSs in a PLMN. The default OFCS addresses (i.e. the primary address and secondary address) shall be locally pre-configured within the PCEF. OFCS addresses may also be passed once per IP‑CAN session from the PCRF to the PCEF. The addresses provided by the PCRF shall have a higher priority than the pre-configured ones.

** The OFCS is connected to the PCEF via the Gz interface.

[I'll keep the pictures numbering for future referencing.]

Figure 5.1.1 Overall PCC logical architecture (non-roaming)

This architecture describes the simplest case where the User Equipment is located in his home network – in the network of the operator he subscribed to.

Figure 5.1.2 Overl PCC architecture (roaming with home routed access)

As the picture shows, here only the BBERF (which can be an SGW or a SGSN) is located in the visited network. This implies that the local (visited) PCRF is also to be used when locating the UE. The visited PCRF will contact the home PCRF via the S9 interface.

Figure 5.1.3 Overall PCC architecture for roaming with PCEF in visited network (local breakout)

This is the case where basically the entire access network is a visited network as the UE is concerned about. The BBERF (SGW or SGSN) and the PCEF (GGSN or SGW) [at least as far as the 3GPP implementations go...WiMAX guys, please help me out complete this article] are in the visited network. This implies: the use of (at least) the local (visited) PCRF, possibly the use of a local AF and the existence of a local OFCS.

This being said, let’s see how the IP-CAN Session Establishment process takes place – shamelessly copy-pasted from TS 23.203 – section 7.2 IP-CAN Session Establishment – with the consideration that, at least this spec is concise enough when describing these procedures so that I won’t feel the need to add anything else (afaik):

** Careful with the local notes, as in this single picture there are represented the IP-CAN procedures for all the 3 roaming/non-roaming scenarios described above:

This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment information between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.

For the Local Breakout scenario (Figure 5.1.3) the V-PCRF shall proxy the Indication and Acknowledge of IP‑CAN Session Establishment over S9 between the PCEF in the VPLMN and the H-PCRF

In the non-roaming case (Figure 5.1.1) the V-PCRF is not involved.

1.   The BBERF initiates a Gateway Control Session Establishment procedure as defined in clause 7.7.1 (applicable for cases 2a during initial attach and 2b, as defined in clause 7.1).

2.   The GW(PCEF) receives a request for IP‑CAN Bearer establishment. A PDN Connection Identifier may be included in the request. The GW(PCEF) accepts the request and assigns an IP address for the user.

3.  The PCEF determines that the PCC authorization is required, requests the authorization of allowed service(s) and PCC Rules information. The PCEF includes the following information: UE Identity (e.g. MN NAI), a PDN identifier (e.g. APN), the IP‑CAN type and the IP address(es), if available, the PDN Connection Identifier received for IP‑CAN Bearer establishment and, if available, the default charging method and the IP‑CAN bearer establishment modes supported. The PDN identifier, IP address(es) and UE identity enables identification of the IP‑CAN session. The IP‑CAN Type identifies the type of access from which the IP‑CAN session is established. If the service data flow is tunnelled at the BBERF, the PCEF shall provide information about the mobility protocol tunnelling encapsulation header. The PCEF may also include the Default Bearer QoS and APN-AMBR (applicable for case 1, as defined in clause 7.1). In case 2a the PCEF may also include charging ID information.

4.   If the PCRF does not have the subscriber’s subscription related information, it sends a request to the SPR in order to receive the information related to the IP‑CAN session. The PCRF provides the subscriber ID and, if applicable, the PDN identifier to the SPR. The PCRF may request notifications from the SPR on changes in the subscription information.

5.   The PCRF stores the subscription related information containing the information about the allowed service(s) and PCC Rules information.

6.   The PCRF makes the authorization and policy decision.

7.  The PCRF sends the decision(s) , including the chosen IP‑CAN bearer establishment mode, to the PCEF. The GW(PCEF) enforces the decision. The PCRF may provide the default charging method and may include the following information: the PCC Rules to activate and the Event Triggers to report. The Policy and Charging Rules allow the enforcement of policy associated with the IP‑CAN session. The Event Triggers indicate to the PCEF what events must be reported to the PCRF.

8.   If online charging is applicable, and at least one PCC rule was activated, the PCEF shall activate the online charging session, and provide relevant input information for the OCS decision. Depending on operator configuration PCEF may request credit from OCS for each charging key of the activated PCC rules.

9.   If online charging is applicable the OCS provides the possible credit information to the PCEF and may provide re-authorisation triggers for each of the credits.

In cases 2a and 2b if the OCS provides any re-authorisation trigger, which can not be monitored at the PCEF, the PCEF shall request PCRF to arrange those to be reported by the BBERF via the PCRF.

10. If at least one PCC rule was successfully activated and if online charging is applicable, and credit was not denied by the OCS, the GW(PCEF) acknowledges the IP‑CAN Bearer Establishment Request.

11. If network control applies the GW may initiate the establishment of additional IP-‑CAN bearers. See Annex A and Annex D for details.

12.  If the PCRF in step 7 requested an acknowledgement based on PCC rule operations, the GW(PCEF) sends the IP‑CAN Session  Establishment Acknowledgement to the PCRF in order to inform the PCRF of the activated PCC rules result.

Many more information on this on TS 23.203. Insist on the QoS parameter interaction.

Specially: Annex 4. 3GPP Accesses (GERAN/UTRAN/E-UTRAN) GTP-based EPC

Tags: , , , , , , , , , , , , , , , , ,

27
Aug

Haydn – TTC

   Posted by: cristina_crow    in media-culture

Din  nou: TTC and Robert Greenberg.

De data aceasta, insa, este despre viata lui Haydn, 15 lectii de aproximativ jumatate de ora. Haydn era super apreciat – desi talentul lui s-a dezvoltat destul de tarziu. Aveam peste 50 de ani, cand englezii, vazand ca sponsorul lui Haydn, printul de Esterhazy, nu-l lasa sa plece de la curtea lui, se gandesc chiar sa-l rapeasca si sa-l aduca in Londra:

By the mid 1780s, most of Haydn’s works were immediately published, then heard across Europe and, for that matter, North America as well. Haydn’s music was embraced in Spain, adored in Italy and France as well as in Germany and Austria. The English in particular worshiped – and that is not too strong a word – worshiped Haydn’s music. Between 1781 and 1787, the English Publishing Firm of William Forester published 129 works by Haydn, of which 82 were symphonies, for which Haydn btw received a beaucoup bucks.

Starting 1783, various English concert societies began inviting Haydn to come over in England to conduct and compose, hang out and get very rich. Unfortunately, and much to Haydn’s unhappiness, he had to decline any and all such offers to travel abroad. There was no chance that Prince Nicholas ” the big shot” – Esterhazy would grant his capel maestro such an extended leave of absence [.....]

[Printul Esterhazy incerca sa-l tina pe Haydn pentru curtea lui, deoarece era clar ca faima lui Haydn l-ar fi determinat sa nu se mai intoarca, nici la monotonia din palatul Esterhazy, dar nici la sotia lui cu care nu se intelegea deloc.]

Haydn’s popularity in England during the late 1780s was such that the press saw his position as little better than imprisonment. Even so far as to suggest that Haydn BE KIDNAPPED and brought to London. I kid you not. The following appeared in the London Review: “There is something very distressing to the liberal mind in the history of Haydn. This wonderful man, who is the Shakespeare of music, and the triumph of the age in which we live is doomed to reside in the court of a miserable German prince, who is once incapable of rewarding him and unworthy of the honor. Haydn, the simplest, as well as the greatest of men, is resigned to his condition and is content to live in a place little better than a dungeon, subject to the dominant spirit of a petty lord and a clamorous spirit of a scolding wife.”

My my – the word DOES get around…..

String Quartet in C Major, Opus 33, nr. 3, “Pasarea”

YouTube Preview Image

Tags: ,