Archive for August, 2010

18. DNS query

The specifics of the SIP information retrieval via DNS queries are described in RFC 3263 – Session Initiation Protocol (SIP): Locating SIP Servers. This RFC details the SIP specificities on top of RFC 2782 – A DNS RR for specifying the location of services (DNS SRV).

In our case, the P-CSCF of the visited domains looks at the Request-URI the UE sent in its Register message. It observes this domain is different than its own, so it concludes the UE is in roaming, so it has to locate the home I-CSCF, in order to see if it can serve this subscriber or not.

So, what steps does the visited P take in order to get to the right home I?

The P performs a NAPTR query for the domain specified in the Request-URI;

This NAPTR thinggie comes from Name Authority Pointer and it is actually a type of DNS RR – Resource Record. The reason behind the invention of this horrible RR is the quest to map everything around the interwebs – we’re mapping you over!!! Resistance is futile !!! HA HA HAAA 😛

Now, seriously, they are trying to map resources like services (like printers, LDAP servers or..why not…I-CSCF servers!!!) to a plain domain name. This NAPTR has a specific structure:

– service name

– set of flags

– regexp rule (yes, regular expressions, we all hate them 😛 , or at least I surely do so, at least after the Perl learning tentative I had a while back)

– an order value

– a preference

– replacement

and, even more, they can also come chained in multiple records carefully cascaded to make our poor lives even more miserable.

These NAPTR things are standardized by RFC 2915 and RFC 3403. Good luck with that!

Moving on, let’s take a look at how a P-CSCF NAPTR Query may look like:

OPCODE=SQUERY

QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPRT

The NAPTR Response would be like this:

OPCODE=SQUERY, RESPONSE, AA

QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPTR

registrar1.home.net       0   IN   NAPTR   50 50 “s” “SIP+D2U” “” _sip._udp.registrar1.home.net

0   IN   NAPTR 90 50 “s” “SIP+D2T” “” _sip._tcp.registrar1.home.net

0   IN   NAPTR 100 50 “s” “SIPS+D2T” “” _sips._tcp.registrar1.home.net

UDP is preferred, as the UDP record appears first – order criteria. The “s” means this is a SRV record. What this P needs to do further on is to perform a SRV Query at the address provided in the NAPTR record first ( _sip._udp.registrar1.home.net) in order to get the services supported by this guy (the I-CSCF).

The SRV Query would look something like this:

OPCODE=SQUERY

QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

And the SRV Response:

OPCODE=SQUERY, RESPONSE, AA

QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

_sip._udp.registrar1.home.net   0   IN   SRV   1   10   5060   icscf1_p.home.net

0   IN   SRV   1   0   5060   icscf7_p.home.net

icscf1_p.home.net   0   IN   AAA   5555::aba:abb:abc:abd

icscf7_p.home.net   0   IN   AAA   555::dba:dbb:dbc:dbd

Here there are listed all the I-CSCF proxies in the home.net domain, with their Priority and Weight. The best one will be chosen, according to the rules defined in RFC 2782. As the answer also contains the IP address of the I-CSCF, the visited P-CSCF will forward the REGISTER message to this I-CSCF (here icscf1), on port 5060.

As I was saying in part 3: let’s get down to business 🙂
The 4G portion of the 4G – IMS registration has been described in Part 1;
The IP-CAN Session Establishment has been described in Part 2;
The generic IMS specifications (at least part of them) have been described in Part 3;

Now, let’s analyze the messages from the IMS – SIP signaling. As I was saying, these messages are tunneled between the eNodeB and PGW via GTPv1-U protocol. Then they reach the P-CSCF and are forwarded in the IMS core. This P-CSCF entity, often called simply P, can be located – and usually it is, specially in the roaming scenarios, … located in the visited network.

Before continuing to the description of each of the messages in the IMS registration, let’s take another look at the 4G – IMS architecture, as well as to the registration flow that we describe:

4g-ims

4G-IMS Architecture

4G-IMS RegistrationFlow

4G-IMS

16. P-CSCF Discovery

– described in TS 23.228: section 5.1.1 Procedures related to Proxy-CSCF discovery and

section E.1.1.1 GPRS/EPS procedure for P-CSCF discovery

Because the procedure is pretty straight-forward, I will just copy-paste it from the spec above:

The Proxy CSCF discovery shall be performed using one of the following mechanisms:
– As part of the establishment of connectivity towards the IP-Connectivity Access Network, if the IP-Connectivity Access Network provides such means.
Alternatively, the P CSCF discovery may be performed after the IP connectivity has been established. To enable P CSCF discovery after the establishment of IP connectivity, the IP-Connectivity Access Network shall provide the following P CSCF discovery option to the UE:
Use of DHCP to provide the UE with the domain name and/or IP address of a Proxy CSCF and the address of a Domain Name Server (DNS) that is capable of resolving the Proxy CSCF name, as described below in clause 5.1.1.1.
The UE may be configured (e.g. during initial provisioning or via a 3GPP IMS Management Object (MO), TS 24.167 [64] or in the ISIM, TS 31.103 [69]) to know the fully qualified domain name (FQDN) of the P CSCF or its IP address. If the domain name is known, DNS resolution is used to obtain the IP address.
In the case where UE is aware of more than one P CSCF address, the selection shall be based on home operator configured policy to select the P CSCF.
NOTE:Subject to home operator policy, the UE selects the Home P CSCF to be used by either using a pre-configured Home P CSCF FQDN or according to TS 24.167 [64]. This can be done without the UE first performing the local P CSCF discovery (e.g. DHCP).

Section 5.1.1.1 describes the DHCP/DNS procedure for P-CSCF discovery:

The DHCP relay agent within the IP-Connectivity Access Network relays DHCP messages between UE and the DHCP server.

p-cscf-dhcp-dns

1.Establish an IP-Connectivity Access Network bearer if not already available by using the procedures available in the IP-Connectivity Access Network.

2.The UE requests a DHCP server and additionally requests the domain name and/or IP address of the P‑CSCF and IP addresses of DNS servers. It may require a multiple DHCP Query/Response message exchange to retrieve the requested information.

3.The UE performs a DNS query to retrieve a list of P‑CSCF(s) IP addresses from which one is selected. If the response does not contain the IP addresses, an additional DNS query is needed to resolve a Fully Qualified Domain Name (FQDN) to an IP address.

After reception of domain name and IP address of a P‑CSCF the UE may initiate communication towards the IM subsystem.

Section E.1.1.1 describes the GPRS/EPS procedure for P-CSCF discovery

I will just show the 4G part, procedure valid for both E-UTRAN Initial Attach procedure, as well as for subsequent PDN Connectivity Requests:

p-cscf-eps-bearer

1.   During Initial Attach/PDN Connection Request, the UE indicates that it requests a P‑CSCF IP address(es).

2.   The MME sends a Create Default Bearer Request to the S‑GW.

3.   The S‑GW forwards the request to the P‑GW and the P‑GW gets the IP address(es) of the P‑CSCF(s). The mechanism to do this is a matter of internal configuration and is an implementation choice.

4.   If requested by the UE, the P‑GW includes the IP address(es) of the P‑CSCF(s) in the Create Default Bearer Response.

5.   The S‑GW forwards the response to the MME

6.   Completion of procedures, as described in TS 23.401 [70].

After reception of the IP address of a P‑CSCF the UE may initiate communication towards the IM CN Subsystem.

17. Register message sent from the IMS terminal to the P-CSCF

Once the IMS terminal obtains its IP address, it must register to the IMS network. This happens in order for the UE to authenticate and obtain authorization to use the IMS network resources. The IMS registration is accomplished by the SIP REGISTER message – this being also the only SIP message that is authenticated by the network (subsequent SIP messages, like INVITE, 200 OK…and so on, are not being authenticated).

First of all, we should know that the IMS-SIP is a SIP (RFC 3261) on steroids (as my SIP colleague use to joke 😛 ), because it has a lot of 3GPP enhancements to meet the 3GPP requirements for this type of communication – I won’t get into details right now. One requirement is that, in IMS, unlike in regular SIP, a phone cannot make any call without first being registered to the IMS network.

Second of all, let’s establish the meaning of this “register” procedure. What the REGISTER procedure does is bind the public URI of that IMS user to a certain IP address and/or host name. The IP address/host name are the ones given by the IP-CAN Session during attach or later on. It is the means of locating that phone in the network. The point is to let the IMS network know at which actual address (IP/host name) it can find a user it has configured as subscriber.

Short note: this public URI thinggie is the identity of the subscriber, something like an e-mail address, only less pretty :P. It can also contain a bunch of weird parameters that I won’t get into details with right now:

examples of SIP URIs:

sip:Alice.Smith@domain.com

sip:Bob.Brown@example.com

sip:carol@ws1234.domain2.com;transport=tcp

SIP URIs with SDP information (SDP – Session Description Protocol) :

v=0

o=Bob 234562566 236376607 IN IP4 192.0.0.2

s=Let’s talk about martial arts

c=IN IP4 22.22.22.22

t=0 0

m=audio 30000 RTP/AVP 0

a=sendrecv

m=video 30002 RTP/AVP 31

a=sendrecv

Before actually taking a look at this fancy SIP REGISTER message, let’s present the IMS requirements for SIP Registration:

[Bear in mind that many of the information below are inspired/taken from the following book:

http://www.amazon.com/3G-IP-Multimedia-Subsystem-IMS/dp/0470871563

The 3G IP Multimedia System: Merging the Internet and the Cellular Worlds

by Gonzalo Camarillo and Miguel-Angel Garcia-Martin ]

The IMS registration procedure satisfies the following requirements in two round trips:

(a) the user binds a Public User Identity to a contact address – this is the main purpose ofa SIP REGISTER request;

(b) the home network authenticates the user;

(c) the user authenticates the home network;

(d) the home network authorizes the SIP registration and the usage of IMS resources;

(e) in case the P-CSCF is located in a visited network, the home network verifies that there is an existing roaming agreement between the home and the visited network and authorizes the usage of the P-CSCF;

(f) the home network informs the user about other possible identities that the homenetwork operator has allocated exclusively to that user;

(g) the IMS terminal and the P-CSCF negotiates the security mechanism that will be in place for subsequent signaling;

(h) the P-CSCF and the IMS terminal establish a set of security associations that protect the integrity of SIP messages sent between the P-CSCF and the terminal;

(i) both the IMS terminal and the P-CSCF upload to each other the algorithms used for compression of SIP messages.

Before creating the SIP Register message, the UE terminal retrieves the Private User Identity from its ISIM card, along with its Public User Identity and its home network domain URI.
OK, so let’s take a look at the actual SIP REGISTER message the IMS terminal sends to its P-CSCF, via the 4G Access Network:
REGISTER sip:registrar1.home.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 70
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
From: <sip:alice_public@home.net>;tag=s8732n
To: <sip:alice_public@home.net>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”alice_private@home.net”,realm=”registrar1.home.net”, nonce=””,uri=”sip:registrar1.home.net”, response=””
Security-Client: ipsec-3gpp; alg=hmac-sha-1-96;spi-c=3929102; spi-s=0293020; port-c:3333; port-s=5059
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Supported: path
Content-Length: 0
1. The first line identifies the method, which is REGISTER, then it is followed by the Request-URI. This Request-URI identifies the destination domain of the Register request.
– this Request-URI has the role of registration URI which identifies the home network or a subdomain of the network
2. The Via header is the IP address ( here: 5555::aaa:bbb:ccc:ddd) given to the UE during the initial attach or bearer activation, statically or dynamically (IP-CAN) assigned.
3. The P-Access-Network-Info represents the access type and information related to the access network, in our case, a 3GPP 4G network – LTE wireless, FDD, with the specified cell id.
4. The To: and From: fields are usually taken from the USIM. These fields have the same value in the Register message, representing the Public User Identity, also called Address-of-Record. This is the identity the other parties know and use to contact this UE.
5. The Contact: header represents the temporary point of presence for this UE. Its value is the most recent IP address the UE has and this address is stored in the S-CSCF. This is the third important parameter about the UE, the Contact Address (the other two being the registration URI and Address-of-Record).
6. The Authorization field caries out authentication information about the terminal. This information is the forth parameter used for registration, having the role of the Private User Identity. This value is the equivalent of the IMSI field in the GSM system and it should not be displayed to the user. It is used by the AKA fields to authenticated the user. This parameter is composed by the private ID and the domain name of the home network where the UE registers.
The nonce and response parameters are empty, because this case considers the terminal has just been turned on for the first time, otherwise there should have been some cached information to send here.
7. The Security-Client field lists the algorithms supported by the UE. In this case, the terminal has IPsec capabilities.
8. The client requires the parties to agree on its security parameters and also indicates it supports the Path header.
Before moving on to the DNS query functions of the P-CSCF, we should know that usually the P-CSCF is not located in the same network as the home network of the UE. This is why it is very possible it does not have an entry point into the user’s home network. Still, in order to be able to serve this UE, the P uses information from the user in order to locate the I-CSCF from the home network. This procedure is a DNS query specified in RFC 3263 and its purpose is to give this P a SIP URI of the home network I. After the P locates this I, it will forward the REGISTER message to the I, inserting along a P-Visited-Network-ID header that identifies the location (domain name of the network) of the P.
This P-Visited-Network-ID is necessary so that the home network verifies it actually has a roaming agreement with the visited network. Also, the P-CSCF inserts its own SIP URI into the Path header, so that the I-CSCF knows where to forward the reply. It is important that the Path header is populated, so that every request from the home network is forwarded via this P-CSCF visited network proxy, otherwise the requests will never reach our roaming subscriber.
— the DNS query procedures in the next episode —

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

Still, before continuing the IMS registration started in windancersth.wordpress.com/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 3327SIP “Path” Extension Header Field for Registering Non-Adjacent Contacts
RFC 3608SIP Extension Header Field for Service Route Discovery during Registration
Diameter:
3GPP TS 29.109GAA – Zh and Zn Interfaces based on the Diameter protocol – Stage 3
3GPP TS 29.229Cx and Dx interfaces based on the Diameter protocol – Protocol Details
3GPP TS 29.230Diameter Applications – 3GPP Specific Codes and Identifiers
3GPP TS 29.329Sh Interface based on the Diameter protocol – Protocol Details
3GPP TS 32.299 Charging Management – Diameter Charging Applications
RFC 3588Diameter Base Protocol
RFC 3589Diameter 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.207Policy Control over Go Interface
3GPP TS 29.208End-to-end Quality of Service (QoS) Signalling Flows
3GPP TS 29.209Policy control over Gq Interface
Charging:
3GPP TS 22.115Service Aspects – Charging and Billing
3GPP TS 32.240Charging 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.210Charging Rule Provisioning over Gx Interface
3GPP TS 29.211Rx Interface and Rx/Gx Signalling Flows
3GPP TS 23.203Policy and Charging Control Architecture
3GPP TS 32.295Charging Data Record (CDR) Transfer
3GPP TS 32.296Online Charging System (OCS): Applications and Interfaces
3GPP TS 32.297Charging Data Record (CDR) File Format and Transfer
3GPP TS 32.298Charging Data Record (CDR) Parameter Description
3GPP TS 32.299Diameter Charging Applications
Security:
3GPP 33-series3GPP Specifications related to Security
QoS:
3GPP TS 23.107Quality of Service (QoS) Concept and Architecture
3GPP TS 23.207End-to-end Quality of Service (QoS) Concept and Architecture
3GPP TS 29.208End-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.198Open Service Access (OSA) – Stage 2
3GPP TS 29.19829.198 series: Open Service Access (OSA) API
3GPP TS 29.19929.199 series: OSA Parlay X Web Services
CAMEL:
3GPP TS 22.078 CAMEL – Service description – Stage 1
3GPP TS 23.078CAMEL Phase 4 – Stage 2
3GPP TS 23.278CAMEL Phase 4 – Stage 2 – IM CN Interworking
3GPP TS 29.078CAMEL Phase X – CAMEL Application Part (CAP) specification
3GPP TS 29.278CAMEL Phase 4 – CAP specification for IP Multimedia Subsystems (IMS)
3GPP TS 29.002Mobile Application Part (MAP) specification
WLAN Access:
3GPP TS 22.234 Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking
3GPP TS 23.2343GPP System to WLAN Interworking – System Description
3GPP TS 24.234 WLAN User Equipment (WLAN UE) to Network Protocols – Stage 3
3GPP TS 29.161Interworking between the PLMN supporting Packet based Services with WLAN Access and PDNs
3GPP TS 29.2343GPP System to WLAN Interworking – Stage 3
3GPP TS 32.252WLAN Charging
3GPP TS 33.234WLAN 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.141Presence Service – Stage 1 – Requirements
3GPP TS 23.141Presence Service – Stage 2 – Architecture and functional description
3GPP TS 24.141Presence service using the IP Multimedia (IM) Core Network (CN) subsystem – Stage 3
3GPP TS 26.141IMS 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.979Push-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.

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

non-roaming

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.

home-routed

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.

local-breakout

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:

ip-can

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

Haydn – TTC

Posted: August 27, 2010 in media-culture
Tags: ,

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”

 

So, let’s talk about 4G and IMS. This will describe the registration to the IMS core, when the IMS equipment is located in a Visited Network, in roaming.

The normal lines (and arrows) represent the main protocol:

– while in the 4G environment (UE, eNodeB, MME, SGW, PGW): it is eGTP (GTPv2-C) protocol

– while in the IMS environment(P-CSCF, I-CSCF, S-CSCF, HSS): it is plain IP or Diameter protocol

The dotted lines (and arrows) represent the inner IP protocol messages, which are encapsulated in GTPv1-U header.

The specs impacted by this are:

TS 23.401 : for the 4G UE equipment Initial Attach to the network

TS 23.203 : description of the IP-CAN Session Establishment procedures

TS 23.228 : description of the P-CSCF Discovery procedures

TS 21.905 : vocabulary for 3GPP Specifications

TS 29.061 : interworking of 4G and IMS

TS 29.212 : PCC (Policy and Charging Control) over Gx interface

TS 29.213 : PPC signaling flows and QoS parameters

TS 24.229 : IP multimedia call control over SIP and SDP

RFC 3261 : SIP – Session Initiation Protocol

The IMS protocols are just too many and diverse to list here all the TSs and RFCs related to them.

4G-IMS

Let’s describe – shortly, very shortly – the messages exchanged here:

[Some of the message descriptions are simply and shamelessly copy-pasted from the spec :p  ]

1. Attach Request [TS 23.401]

The UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request (IMSI or old GUTI, last visited TAI (if available), UE Core Network Capability, UE Specific DRX parameters, PDN Type, Protocol Configuration Options, Ciphered Options Transfer Flag, Attach Type, KSIASME, NAS sequence number, NAS-MAC, additional GUTI, P-TMSI signature) message together with RRC parameters indicating the Selected Network and the old GUMMEI. The old GUTI may be derived from a P TMSI and RAI. IMSI shall be included if the UE does not have a valid GUTI or a valid P TMSI available. The UE stores the TIN in detached state. If the UE’s TIN indicates “GUTI” or “RAT-related TMSI” and the UE holds a valid GUTI then the old GUTI indicates this valid GUTI. If the UE’s TIN indicates “P TMSI” and the UE holds a valid P TMSI and related RAI then these two elements are indicated as the old GUTI. Mapping a P TMSI and RAI to a GUTI is specified in TS 23.003 [9]. If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI and the UE has a valid P-TMSI signature associated to it, the P-TMSI signature shall be included.
If available, the last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent Attach Accept message. Selected Network indicates the PLMN that is selected for network sharing purposes. The RRC parameter “old GUMMEI” takes its value from the “old GUTI” contained in the Attach Request. UE Network Capability is described in UE capabilities, see clause 5.11.
If the UE has valid security parameters, the Attach Request message shall be integrity protected by the NAS-MAC in order to allow validation of the UE by the MME. KSIASME, NAS sequence number and NAS-MAC are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of the NAS message. If the UE does not have a valid EPS security association, then the Attach Request message is not integrity protected. In this case the security association is established in step 5a. The UE network capabilities indicate also the supported NAS and AS security algorithms. PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the PDN GW, and are sent transparently through the MME and the Serving GW. The Protocol Configuration Options may include the Address Allocation Preference indicating that the UE prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE intends to send PCO which require ciphering (e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set the Ciphered Options Transfer Flag and send PCO or APN or both only after authentication and NAS security setup have been completed (see below). If the UE has UTRAN or GERAN capabilities, it should send the NRSU in the PCO to indicate the support of the network requested bearer control in UTRAN/GERAN. Attach Type indicates “Handover” when the UE has already an activated PDN GW/HA due to mobility with non-3GPP accesses.

2. Attach Request [TS 23.401]

The eNodeB derives the MME from the RRC parameters carrying the old GUMMEI and the indicated Selected Network. If that MME is not associated with the eNodeB or the old GUMMEI is not available, the eNodeB selects an MME as described in clause 4.3.8.3 on “MME selection function”. The eNodeB forwards the Attach Request message to the new MME contained in a S1-MME control message (Initial UE message) together with the Selected Network and TAI+ECGI of the cell from where it received the message to the new MME.

3. Create Session Request [TS 23.401]

If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the UE’s IPv4 address and/or the IPv6 prefix and optionally the PDN GW identity. In case the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. For Attach Type indicating “Initial Attach”, if the UE does not provide an APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation. If the UE provides an APN, this APN shall be employed for default bearer activation. For Attach type indicating “Handover”, if the UE provides an APN, the MME shall use the PDN GW corresponding to the provided APN for default bearer activation, If the UE does not provide an APN, and the subscription context from HSS contains a PDN GW identity corresponding to the default APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation. The case where the Attach type indicates “Handover” and the UE does not provide an APN, and the subscription context from HSS does not contain a PDN GW identity corresponding to the default APN constitutes an error case. If the attach type indicates “Initial Attach” and the selected PDN subscription context contains no PDN GW identity the new MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW selection function (3GPP accesses). If the PDN subscription context contains a dynamically allocated PDN GW identity and the Attach Type does not indicate “Handover” the MME may select a new PDN GW as described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient routing. The new MME selects a Serving GW as described in clause 4.3.8.2 on Serving GW selection function and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, RAT type, Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, the Protocol Type over S5/S8) message to the selected Serving GW.

The RAT type is provided in this message for the later PCC decision. The subscribed APN AMBR for the APN is also provided in this message. The MSISDN is included if provided in the subscription data from the HSS. Handover Indication is included if the Attach type indicates handover. Selection Mode indicates whether a subscribed APN was selected, or a non-subscribed APN sent by the UE was selected.. Charging Characteristics indicates which kind of charging the bearer context is liable for. The MME may change the requested PDN type according to the subscription data for this APN as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag when the PDN type is set to IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is determined based on node pre-configuration by the operator. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.

 

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of handling Charging Characteristics and whether to send them or not to the P GW is defined in TS 32.251 [44]. The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S GW and/or P GW trace is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.

The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4 of TS 23.060 [7]). If the P GW receives the Maximum APN Restriction, then the P GW shall check if the Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with sending an appropriate error cause to the UE.

NOTE 7:The Dual Address Bearer Flag is not used when the Protocol Type over S5/S8 is PMIP.

4. Create Session Request [TS 23.401]
The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information (ECGI), MS Info Change Reporting support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag) message to the PDN GW indicated by the PDN GW address received in the previous step. After this step, the Serving GW buffers any downlink packets it may receive from the PDN GW without sending a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message in step 23 below. The MSISDN is included if received from the MME.
5. IP-CAN Session Establishment [TS 23.203] – next episode
6. Create Session Response [TS 23.401]
The P GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows the P GW to route user plane PDUs between the S GW and the packet data network, and to start charging. The way the P GW handles Charging Characteristics that it may have received is defined in TS 32.251 [44].
The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start) (if the PDN GW decides to receive UE’s location information during the session), APN-AMBR) message to the Serving GW. The PDN GW takes into account the received PDN type, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the PDN type to be used as follows. If th received PDN type is IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing for this APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the received PDN type is IPv4 or IPv6, the PDN GW uses the received PDN type if it is supported in the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN type. If the PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates together with the PDN type IE a reason cause to the UE why the PDN type has been modified, as described in clause 5.3.1.1. PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix and an Interface Identifier. If the PDN has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN GW allows the UE to use DHCPv4 for address allocation according to the Address Allocation Preference received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be negotiated by the UE with DHCPv4 after completion of the Default Bearer Activation procedure. In case of external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN GW includes the Interface Identifier and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases.
If the PDN address is contained in the Create Session Request, the PDN GW shall allocate the IPv4 address and/or IPv6 prefix contained in the PDN address to the UE. The IP address allocation details are described in clause 5.3.1 on “IP Address Allocation”. The PDN GW derives the BCM based on the NRSU and operator policy. Protocol Configuration Options contains the BCM as well as optional PDN parameters that the P GW may transfer to the UE. These optional PDN parameters may be requested by the UE, or may be sent unsolicited by the P GW. Protocol Configuration Options are sent transparently through the MME.

7. Create Session Response
[TS 23.401]
If the MS Info Change Reporting Action (Start) is received for this bearer context, then the S GW shall store this for the bearer context and the S GW shall report to that P GW whenever a UE’s location change occurs that meets the P GW request, as described in clause 15.1.1a of TS 23.060 [7].
The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Identity, EPS Bearer QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action (Start), APN-AMBR) message to the new MME.

8. Initial Context Setup Request/ Attach Accept[TS 23.401]
If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the Bearer Context is accepted, the MME shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction.
If the MS Info Change Reporting Action (Start) is received for this bearer context, then the MME shall store this for the bearer context and the MME shall report whenever a UE’s location change occurs that meets the request, as described in clause 15.1.1a of TS 23.060 [7].
The MME determines the UE AMBR to be used by the eNB based on the subscribed UE-AMBR and the APN AMBR for the default APN, see clause 4.7.3.
The new MME sends an Attach Accept (APN, GUTI, PDN Type, PDN Address, TAI List, EPS Bearer Identity, Session Management Request, Protocol Configuration Options, KSIASME, NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication) message to the eNodeB. GUTI is included if the new MME allocates a new GUTI. This message is contained in an S1_MME control message Initial Context Setup Request. This S1 control message also includes the AS security context information for the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer Identity, as well as the TEID at the Serving GW used for user plane and the address of the Serving GW for user plane. In the Attach Accept message, the MME does not include the IPv6 prefix within the PDN Address. The MME includes the EPS Bearer QoS parameter QCI and APN-AMBR into the Session Management Request. Furthermore, if the UE has UTRAN or GERAN capabilities, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in the Session Management Request. If the UE indicated in the UE Network Capability it does not support BSS packet flow procedures, then the MME shall not include the Packet Flow Id. Handover Restriction List is described in clause 4.3.5.7 “Mobility Restrictions”. The MME sets the IMS Voice over PS session supported Indication as described in clause 4.3.5.8.
If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as described in clause 5.3.1.1.
9. RRC Connection Reconfiguration[TS 23.401]
The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE. The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session Management Request, for use when accessing via GERAN or UTRAN. The APN is provided to the UE to notify it of the APN for which the activated default bearer is associated. For further details, see TS 36.331 [37]. The UE may provide EPS Bearer QoS parameters to the application handling the traffic flow(s). The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session Management Request.
When receiving the Attach Accept message the UE shall set its TIN to “GUTI” as no ISR Activated is indicated.
If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in TS 29.061 [38]. If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from the network with the IPv6 prefix information or it may send a Router Solicitation if necessary.
NOTE 10:The IP address allocation details are described in clause 5.3.1 on “IP Address Allocation”.
10. RRC Connection Reconfiguration Complete[TS 23.401]
The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. For further details, see TS 36.331 [37].
11. Initial Context Setup Response[TS 23.401]
The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point.
12. Direct Transfer[TS 23.401]
The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete (EPS Bearer Identity, NAS sequence number, NAS-MAC) message.
13. Attach Complete[TS 23.401]
The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message.
After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW. If the UE requested for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) by the network with a reason cause indicating that only single IP version per PDN connection is allowed sent together with the PDN type, the UE may request for the activation of a parallel PDN connection to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.
14. Modify Bearer Request[TS 23.401]
Upon reception of both, the Initial Context Response message in step 21 and the Attach Complete message in step 22, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication) message to the Serving GW.
15. Modify Bearer Response[TS 23.401]
The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) message to the new MME. The Serving GW can then send its buffered downlink packets.
—— in the next episode —–
16. P-CSCF Discovery
17. Register
18. DNS Query
19. Register
20. Diameter UAR
21. Diameter UAA
22. Register
23. Diameter MAR
24. Diameter MAA
25. 401 Unauthorized
26. 401 Unauthorized
27. 401 Unauthorized
28. Register
29. Register
30. Diameter UAR
31. Diameter UAA
32. Register
33. Diameter SAR
34. Diameter SAA
35. 200OK
36. 200OK
37. 200OK

IMS

Posted: August 25, 2010 in technical
Tags: , ,

Where do I start? What do I learn first?

After all, it is not that complicated in the first place:

IMS

[TS 23.228]

TS 29.061, more precisely the Interworking between PGW and PDN, sections 11 to 13.

TS 23.401, sections 5.3.1 – IP Address Allocation, 5.3.2 – Attach Procedure

It seems that:

1. an UE can simultaneously connect to multiple APNs;

2. an UE can have multiple default bearers per APN connection: for example, one for IPv4 and one for IPv6;

2.a) 2 default bearers per APN connection are possible when the MME does NOT set the Dual Address Bearer Flag; this way, the MME forces the sending of separate IPv4 and IPv6 requests for PDN connectivity;

2.b) if the MME sets the Dual Address Bearer Flag, then it can send a request with dual-stack IPv4v6 and the APN can provide both of these IP addresses at once – this means that there are 2 IP addresses (one IPv4 and one IPv6 ONLY one of each type !) for a SINGLE default bearer;

3. Allocation of these IP addresses to the UE can happen from a local PGW pool or from the PDN. In the later case, the Create Session Response message sent from the PGW to the SGW (and further on to the MME) has PAA = 0.0.0.0, following the later completion of this address;

3.a) If the PGW has nothing to do with the further negotiation of the IP addresses, we are talking about a direct transparent access IP allocation; the PGW is just a proxy;

3.b) If the PGW is actively (protocol dependent) implicated in the IP address allocation, then we are talking about a non transparent access; the PGW is an active part in the IP negotiation: for instance, it may act as a DHCP server for the UE (via SGW, of course) and in the same time as DHCP client – when talking to the APN’s actual DHCP server;

*Note: the role of the PGW in the DHCP allocation case is different from the role of its 3G homologous, the GGSN – this entity playing the role of a DHCP relay agent in this scenario;

*Note: We are talking about the so-called IP-CAN (Connectivity to Access Network) session establishment – which, as far as I understand from TS 29.061, refers to the process of allocating an IP address (IPv4, IPv6 or IPv4v6) by a process other than gathering it from the PGW pool, for instance: via DHCP/DHCP-PD, PPP, IMS CN IM process…etc…

4. IP-CAN can be established at:

a) Initial Attach (default bearer activation) to the APN (in EPC) – Primary PDP Context Activation to the APN (in 3G)

b) after the initial attach, via a dedicated bearer/secondary PDP context

5. The IP assignment can take place:

a) either at the subscription phase – in which case we are talking about a static address

b) or at the IP-CAN session establishment – in which case we are talking about a dynamic address

*Note: Usually, as part of the IP-CAN negotiation ( no matter if this takes place at initial attach of afterwards), the PGW may request the UE to authenticate to the external APN’s AAA server

eventhelix

Posted: August 16, 2010 in technical
Tags: , , , , , , ,

I’ve kept saying I was going to post this:

http://eventhelix.com/

May 30, 2010 Long Term Evolution (LTE) Presentations
Nov 01, 2009 Long Term Evolution (LTE) Packet Data Convergence Protocol (PDCP) Presentation PDF
Oct 18, 2009 Long Term Evolution (LTE) Tutorials (Updated)
May 10, 2009 Long Term Evolution (LTE) Radio Link Control (RLC) Presentation PDF
Mar 29, 2009 Long Term Evolution (LTE) Medium Access Control (MAC) Presentation PDF
Mar 05, 2009 IMS Registration – EventStudio FDL Download ZIP
Mar 03, 2009 IMS Originating to IMS Terminating Call – EventStudio FDL Download ZIP
Mar 01, 2009 LTE/SAE Tracking Area Update Sequence Diagram PDF
Feb 09, 2009 LTE/SAE Attach Sequence Diagram PDF
Dec 07, 2008 Long Term Evolution (LTE) Tutorials

In  my opinion, a very good tutorial website for LTE – radio. The EPC part is kindda old – it presents the March 2009 spec, but still good for the general idea.

Enjoy!

4G – IMS – take 2

Posted: August 13, 2010 in technical
Tags: , , , , , , , ,

Doing some more reading in the TS 29.061, I ended up in some other dilemmas.

The following information results from this spec so far (as per my understanding):

1. the PGW acts as a “proxy” for the SIP-IMS messages, encapsulating them in GTPv1-U

2. in order for the PGW to locate the P-CSCF, this PGW can have a pre-configured list of P-CSCFs

3. when the UE connects to that APN, the PGW must look through the list of pre-configured Ps, verify which ones are still up (by using ICMP, for example) and send to the UE a list of Ps; if there are multiple Ps in the list, the PGW will use the PCO IE to provide to the UE a prioritized list of Ps

Now, the dilemma comes. As the PGW is a control-plane entity and a user-plane entity in the 4G world, it can send both 4G control-plane messages (to the SGW – that may propagate or not till the MME – GTPv2-C messages) and user-plane messages (which are GTPv1-U messages encapsulating SIP, DHCP, whatever protocol).

TS 29.061 states the following, about how the PGW sends the IP / IPs of the P-CSCF to the UE: – section 13a.2.2  IMS Specific Procedures in the GGSN/P-GW:

The GGSN/P-GW shall then provide only those P-CSCF address(es) that are available in a Create PDP Context Response/Create Bearer Response.

Now, there are 2 issues with this statement:

1. the Create Bearer Response message is actually sent FROM the MME/SGW TO the PGW; the PGW is the one sending the Create Bearer Request message

2. disregarding item 1 and only thinking about the fact that the PGW will send the IP of the P-CSCF as part of the GTPv2-C signaling (rather the proxying it via the GTPv1-U tunnel), TS 29.274 leaves no room for more IEs in the Bearer Context grouped IE:

Table 7.2.3-2: Bearer Context within Create Bearer Request

Octets 1 Bearer Context IE Type = 93 (decimal)
Octets 2 and 3 Length = n
Octets 4 Spare and Instance fields
Information elements P Condition / Comment IE Type Ins.
EPS Bearer ID M This IE shall be set to 0. EBI 0
TFT M This IE can contain both uplink and downlink packet filters to be sent to the UE.  Downlink packet filters are also used by SGW for PMIP based S5/8 interfaces. Bearer TFT 0
S1-U SGW F-TEID C This IE shall be sent on the S11 interface if the S1-U interface is used. F-TEID 0
S5/8-U PGW F-TEID C This IE shall be sent on the S4, S5/S8 and S11 interfaces. F-TEID 1
S12 SGW F-TEID C This IE shall be sent on the S4 interface if the S12 interface is used. F-TEID 2
S4-U SGW F-TEID C This IE shall be sent on the S4 interface if the S4-U interface is used. F-TEID 3
Bearer Level QoS M Bearer QoS 0
Charging Id C This IE shall be sent on the S5/S8 interface. Charging Id 0
Bearer Flags O Applicable flags are:

–          PPC (Prohibit Payload Compression)

Bearer Flags 0

So, if the 3GPP guys actually claim to configure multiple P-CSCF addresses in the above grouped IE, where are they putting those IP addresses?

where:

IMS – IP Multimedia Subsystem

P-CSCF – Proxy Call Session Control Function

PGW – PDN Gateway

PDN – Packet Data Network

SGW – Serving Gateway

MME – Mobility Management Entity

UE – User Equipment

IE – Information Element

GTP – GPRS Tunneling Protocol