Dear Ms. <ME is Here>,

On behalf of the Editorial Board it is my pleasure to inform you that your chapter has been provisionally accepted for publication in the book under the working title  ”Cryptography / Book 1″, ISBN 979-953-307-478-7.

Your next step is to write the full chapter. After the full chapter review, you will receive notification regarding the definitive acceptance of your work in the book.

In the attachment you can find the complete review outcome. From now on, you will be able to see the tentative list of contributing authors and read the accepted chapter proposals.

Tags: 4G, IMS, intech, ipsec, passion, techie

3GPP IMS Specs

3GPP2 IMS Specs

3GPP2 IMS Specs

Tags: 3GPP, 3gpp2, IMS, techie

Helloooo, agaaainnn!!! Long time no see, 4G

Let’s have a short (very short) talk about this DAF thinggie. DAF stands for Dual Address Bearer and it is a flag only set in the Create Session Request message, sent from the MME to the SGW, over the S11 interface. Details about this funky flag are in TS 23.401 (Section 5.3.2.1 E-UTRAN Initial Attach and Section 5.3.1 IP Address Allocation) and in TS 29.274 (Table 7.2.1-1 Information Elements in Create Session Request) and…might be in other TSs also, but I have no idea about those

So, when and why we do use this flag? Mwell, TS 29.284 says the following:

DAF – Conditional :  Dual Address Bearer Flag: This flag shall be set to 1 when the UE requests a PDN type IPv4v6 and all SGSNs which the UE may be handed over to support dual addressing. This shall be determined based on node pre-configuration by the operator.

So, this flag is an indication sent from the MME to the SGW, telling the SGW at the moment of the Initial Attach procedure: Hey! you know what? My mobile device supports dual-stack. You can assign it at once, on the same bearer, both an IPv4 and an IPv6.

Also, if the UE moves from a 3G coverage to a 4G coverage (the definition above says the other way around, but logic tells me that the MME actually sends a Create Session Request when it is a _target_ MME, therefore when the UE moves from a 3G to a 4G network), doing an MME relocation, SGW relocation handover procedure, our MME would says the following to its fellow SGW: Dear SGW, my mobile device has just arrived here from a 3G network, more specifically from an SGSN that supports dual addressing. So don’t worry that I am asking for both an IPv4 and IPv6 addresses for the same bearer for this UE.

Now, there are several rules when using or not this DAF. The general rule is to set it, which seems to be the default rule in the 4G network context.

The only case when, in a 4G context we do NOT set this flag is when the interface between the SGW and the PGW (the S5/S8 interface) runs PMIP, and not GTPv2 (as S11 does).

So, usually, in this most common case, the UE that supports dual-stack will ask for a single default bearer, having an IPv4v6 dual-stack type of address. If the MME is running in a full 4G environment or it is aware that all SGSNs to which the user may handover to also support dual-stack and the MME is aware that the S5/S8 interface runs GTPv2, then the MME will set the DAF flag and hopefully the PGW also supports dual-stack, our dear UE will get an IPv4v6 address, actually meaning that it will get 2 IP addresses (one IPv4 and one IPv6) for the same, single, default bearer to this  APN.

But, even if the UE says it supports dual-stack, but the MME considers, for some reasons it has (it is aware of non-compatible SGSN, or it knows about S5/S8 running PMIP or whatever), not to set the DAF flag, then the UE’s type of address remains to be decided by the PGW….as it follows:

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

What about the UE. What should it do after getting an IP?

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.

Now, the applications on the UE must know which type of socket to create. They can either create an IPv4 or an IPv6 socket and choose among the available IP addresses.

Tags: attach procedure, dedicated bearer, default bearer, DHCP, IMS, LTE, MME, passion, PDN, PGW, SAE, SGW, techie, UE

JJC, Journal of Communication and Computer a citit lucrarea mea despre SIP si IMS.

A Solution for Secure SIP Conferencing over IMS and SAE

si vor sa o republice, din pacate nu prea se poate asta, desi nu m-ar deranja sa apara lucrarea in Library of U.S Congress (http://catalog.loc.gov/)

Dear Dr. CRISTINA,

These are Journal of Communication and Computer (ISSN: 1548-7709, USA) & Computer Technology and Application (ISSN: 1543-7332, USA).

We have read your excellent paper ‘ A Solution for Secure SIP Conferencing over IMS and SAE ‘ from ‘The 4th EUROPEAN COMPUTING CONFERENCE (ECC ’10)‘ and we are pleased to pass on our regards to you. We are very interested in your research, if the paper mentioned has not been published in other journals or you have other unpublished papers in hand and have the idea of making our journals a vehicle for your research interests, please feel free to send electronic version to us.

JCC & CTA are collected and indexed by the Library of U.S Congress, on whose official website (http://catalog.loc.gov) an on-line inquiry can be triggered with their publication number, ISSN1548-7709 & ISSN1543-7332, as key words in “Basic Search” column. The journals are also retrieved by some renowned databases:

«     Database of EBSCO, Massachusetts, USA

«     Chinese Database of CEPS, American Federal Computer Library Center(OCLC), USA

«     Database of Cambridge Science Abstracts (CSA), USA

«     Ulrich’s International Periodicals Directory, USA

«     Summon Serials Solutions

In addition, JCC is also retrieved by Chinese Scientific Journals Database, VIP Corporation, Chongqing, China

Tags: IMS, me happy, passion, sip, techie

This is a summary of what I hope to be able to describe in the next several posts: the establishment of a basic SIP-IMS call flow, in a somewhat interesting scenario: when both Alice and Bob are in roaming.

Each of the participants talks to his/her own P, S and I servers. Here the presumption is that Alice is the one making the phone call.

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, PRACK, Register, S-CSCF, SGW, sip, strict routing, techie, UE

“c1″ because…mwell, because “a” was the register and 4G/IMS architecture, “b” was the OpenIMSCore and “c” should be an actual call flow.

Unfortunately, I cannot show you the actual 4G encapsulation, because I don’t have any tool to emulate that, but, as we’ve understood from the registration flow, each IMS message coming from or going to the IMS mobile device will be encapsulated in GTPv1-u header between the eNodeB, SGW, PGW and then forwarded, without the GTPv1-u encapsulation, to the P-CSCF. Juuust as for the Register flow…

Oook, now let’s take a look at the IMS-SIP call flow. Basically, what I’m going to show here is a Basic Call with Voice.

Now, the most basic SIP (Session Initiation Protocol) call flow has the following structure:

Basically, Alice sends an INVITE message to Bob (via a sip proxy server or directly), inviting Bob to a voip message exchange, and also sending in the SDP (Session Description Protocol) header (presented as a SIP message body), the RTP (Real-Time Protocol) codecs that Alice’s phone is supporting. 1xx is provisional messaging. 100 Trying and 180 Ringing is a good sign, they mean I am actually contacting Bob, I am just waiting for him to pick-up the phone. When he does that, his device signals a 200 OK (sending in this message also the RTP codecs known by Bob’s device), and Alice’s device Acknowledges. Now the RTP session can begin, with one of the matching codecs. Once the two guys finish talking, Alice’s phone (usually) is the one signaling the end of the conversation, by sending a BYE message to Bob, and this one acknowledges. Alice can also send her supported RTP codecs barely in her ACK message, procedure called late negotiation.

Now, this may rightfully seem simple enough, but wait! We haven’t yet got to the IMS part

The same “basic” SIP call flow in the IMS context would look like this (of course, excluding the 4G encapsulation which we’ve agreed we understand):

In the next chapter I’ll detail these messages.

For the moment, let’s just observe the presence of a weird new message called PRACK. The PRACK is defined in RFC3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). The RFC 3262 states:

   The PRACK request plays the same role as ACK, but for
   provisional responses.  There is an important difference, however.
   PRACK is a normal SIP message, like BYE.  As such, its own
   reliability is ensured hop-by-hop through each stateful proxy.  Also
   like BYE, but unlike ACK, PRACK has its own response.  If this were
   not the case, the PRACK message could not traverse proxy servers
   compliant to RFC 2543 [4]."

I believe the IETF guys are pretty explanatory

See you in the next chapter.

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, PRACK, Register, S-CSCF, SGW, sip, strict routing, techie, UE

WONDERFUL tool. Kindda weird to configure at first, but, once you have clear in mind what you want to do, it seems really intuitive.

I have it on a debian 5.0.5. Installed in /opt/OpenIMSCore

It has 4 main components:

P-CSCF, I-CSCF, S-CSCF and HSS – and, as far as I have understood from my knowledgeable colleagues who have done this, these components can be installed separately on different machine. I have installed them bulky on a single machine.

Ah, and it needs a DB server (HSS being a DB afterall) – I have used MySQL and a DNS server – I have used bind9, on the same machine. The Fraunhofers are nice guys and give you the DNS file zone and a lot of scripts to make your work of configuring the proxies, as well as adding and managing users, much easier.

So, briefly, where are the configuration files, what I have changed in each of them to make them work, which scripts I have used and what users I have (the IMS dumps from the previous post shows a user called Cristina who registers to this IMS core and does a SIP call – we’ll see that also).

imacandi:/opt/OpenIMSCore# ls

add-imscore-user_newdb.sh  dbdump.sh                 fhoss.sh        icscf.thig.sh  pcscf.cfg       scscf.cfg  TGPPGq.xml      trcf.sh

add-user-cristina.sql      delete-user-cristina.sql  icscf.cfg       icscf.xml      pcscf.sh        scscf.sh   TGPPRx.xml

add-user-sin.sql           delete-user-sin.sql       icscf.sh        mgcf.cfg       pcscf.xml       scscf.xml  tls_prepare.sh

configurator.sh            FHoSS                     icscf.thig.cfg  mgcf.sh        remove_sems.sh  ser_ims    trcf.cfg

/opt/OpenIMSCore/pcscf.cfg

/opt/OpenIMSCore/icscf.cfg

/opt/OpenIMSCore/scscf.cfg

/opt/OpenIMSCore/FHoSS/deploy/DiameterPeerHSS.xml

listen=22.22.22.22

port=4060

alias=”pcscf.open-ims.test”:4060

<Acceptor port=”3867″ bind=”22.22.22.22″/>

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, strict routing, techie, UE

Continuing from 4G – GTPv2 dumps:

First of all, bare in mind that this is NOT the actual end-to-end testing procedure, so I can only show so far a basic IMS call coming from plain IP, therefore with no indication to the Access Network:

Register

The P-CSCF listens on port 4060 UDP (as we will see in the next episode, the configuration of the IMS Core), and the phone is on 5060:

Session Initiation Protocol

Request-Line: REGISTER sip:open-ims.test SIP/2.0

Method: REGISTER

Request-URI: sip:open-ims.test

Request-URI Host Part: open-ims.test

[Resent Packet: False]

Message Header

Call-ID: [email protected]

CSeq: 19 REGISTER

Sequence Number: 19

Method: REGISTER\r\nFrom

From: <sip:[email protected]>;tag=1020

SIP from address: sip:[email protected]

SIP from address User Part: cristina

SIP from address Host Part: open-ims.test

SIP tag: 1020

To: <sip:[email protected]>

SIP to address: sip:[email protected]

SIP to address User Part: cristina

SIP to address Host Part: open-ims.test

Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021

Transport: UDP

Sent-by Address: 40.0.0.1

Sent-by port: 5060

Branch: z9hG4bK163b18a8645e3542f3430be441fc7021

Max-Forwards: 20

Expires: 3600

Contact: <sip:[email protected]:5060>

Contact-URI: sip:[email protected]:5060

Contactt-URI User Part: cristina

Contact-URI Host Part: 40.0.0.1

Contact-URI Host Port: 5060

User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT

Content-Length: 0

Session Initiation Protocol

Status-Line: SIP/2.0 401 Unauthorized – Challenging the UE

Status-Code: 401

Message Header

Call-ID: [email protected]

CSeq: 19 REGISTER

Sequence Number: 19

Method: REGISTER\r\nFrom

From: <sip:[email protected]>;tag=1020

SIP from address: sip:[email protected]

SIP from address User Part: cristina

SIP from address Host Part: open-ims.test

SIP tag: 1020

To: <sip:[email protected]>;tag=d7837ce6bbd631122d10546eb75bb4cf-cb8c

SIP to address: sip:[email protected]

SIP to address User Part: cristina

SIP to address Host Part: open-ims.test

SIP tag: d7837ce6bbd631122d10546eb75bb4cf-cb8c

Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021

Transport: UDP

Sent-by Address: 40.0.0.1

Sent-by port: 5060

RPort: 5060

Branch: z9hG4bK163b18a8645e3542f3430be441fc7021

Path: <sip:[email protected]:4060;lr>

Service-Route: <sip:[email protected]:6060;lr>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO

Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))

Content-Length: 0

Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19702 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3″

WWW-Authenticate: Digest realm=”open-ims.test”, nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”, algorithm=AKAv1-MD5, qop=”auth,auth-int”

Authentication Scheme: Digest

realm=”open-ims.test”

nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”

algorithm=AKAv1-MD5

qop=”auth

- the one with credentials

Session Initiation Protocol

Request-Line: REGISTER sip:open-ims.test SIP/2.0

Method: REGISTER

Request-URI: sip:open-ims.test

Request-URI Host Part: open-ims.test

[Resent Packet: False]

Message Header

Call-ID: [email protected]

CSeq: 20 REGISTER

Sequence Number: 20

Method: REGISTER\r\nFrom

From: <sip:[email protected]>;tag=1021

SIP from address: sip:[email protected]

SIP from address User Part: cristina

SIP from address Host Part: open-ims.test

SIP tag: 1021

To: <sip:[email protected]>

SIP to address: sip:[email protected]

SIP to address User Part: cristina

SIP to address Host Part: open-ims.test

Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc

Transport: UDP

Sent-by Address: 40.0.0.1

Sent-by port: 5060

Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc

Max-Forwards: 20

[truncated] Authorization: Digest username=”[email protected]”,uri=”sip:open-ims.test”,realm=”open-ims.test”,nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”",response=”edfe66ab211e300fea4da5bd308605c3″,algoritm=AKAv1-MD5,qop=auth-int

Authentication Scheme: Digest

username=”[email protected]”

uri=”sip:open-ims.test”

realm=”open-ims.test”

nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”"

response=”edfe66ab211e300fea4da5bd308605c3″

algoritm=AKAv1-MD5

qop=auth-int

nc=00000001

cnonce=”48525798509797101″

Expires: 3600

Contact: <sip:[email protected]:5060>

Contact-URI: sip:[email protected]:5060

Contactt-URI User Part: cristina

Contact-URI Host Part: 40.0.0.1

Contact-URI Host Port: 5060

User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT

Content-Length: 0

Session Initiation Protocol

Status-Line: SIP/2.0 200 OK – SAR succesful and registrar saved

Status-Code: 200

[Resent Packet: False]

[Request Frame: 81]

[Response Time (ms): 106]

Message Header

Call-ID: [email protected]

CSeq: 20 REGISTER

Sequence Number: 20

Method: REGISTER\r\nFrom

From: <sip:[email protected]>;tag=1021

SIP from address: sip:[email protected]

SIP from address User Part: cristina

SIP from address Host Part: open-ims.test

SIP tag: 1021

To: <sip:[email protected]>;tag=d7837ce6bbd631122d10546eb75bb4cf-3d08

SIP to address: sip:[email protected]

SIP to address User Part: cristina

SIP to address Host Part: open-ims.test

SIP tag: d7837ce6bbd631122d10546eb75bb4cf-3d08

Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc

Transport: UDP

Sent-by Address: 40.0.0.1

Sent-by port: 5060

RPort: 5060

Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc

P-Associated-URI: <sip:[email protected]>

Contact: <sip:[email protected]:5060>;expires=3600

Contact-URI: sip:[email protected]:5060

Contactt-URI User Part: cristina

Contact-URI Host Part: 40.0.0.1

Contact-URI Host Port: 5060

Contact parameter: expires=3600

Path: <sip:[email protected]:4060;lr>

Service-Route: <sip:[email protected]:6060;lr>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO

Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))

Content-Length: 0

Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19703 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3″

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, strict routing, techie, UE

Knowing it is not very nice to talk a lot about a certain thing, but to offer no tangible results, I’ve tried to create some minimal dump information for the things discussed lately on my posts.

They should be, though not end-to-end results, at least some hope-by-hope information.

So, let’s see first how an Initial Attach to the 4G network would look like, then how the UE asks for a dedicated bearer to put traffic on (specifically to put VoIP traffic on), and then take a closer look at a IMS call flow.

For the 4G dumps I must give credit to the wonderful company I work in, which helps me develop on the 4G core network side. While the IMS flows are generated using OpenIMSCore and Monster, the 2 solutions from the cool guys from Fraunhofer.

While my company’s solution is proprietary and closed-source, I would rather recommend you to buy it, but I am not able to give so much details on its architecture , the Fraunhofer solution is free and open-source and is nicely installed on a debian .

So, let’s first take a look at the attach procedure, which is captured on the S11 4G interface, between the MME and the SGW. The message here are Create Session Request and Create Session Response.

GTPv2 runs over UDP, so I’ll just show the message from the GTPv2 control-plane message above in the TCP/IP stack:

First the Create Session Request, coming from the MME to the SGW, by which the UE asks for an IP address and connectivity the PDN – Packet Data Network:

GPRS Tunneling Protocol V2

Create Session Request

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Create Session Request (32)

Message Length: 201

Tunnel Endpoint Identifier: 0

Sequence Number: 7660

Spare: 45056

International Mobile Subscriber Identity (IMSI) :

IE Type: International Mobile Subscriber Identity (IMSI) (1)

IE Length: 8

000. …. = CR flag: 0

…. 0000 = Instance: 0

IMSI(International Mobile Subscriber Identity number): 220614000000001

MSISDN :

IE Type: MSISDN (76)

IE Length: 6

000. …. = CR flag: 0

…. 0000 = Instance: 0

Country Code: 40 Romania length 2

Address digits: 700000001

Mobile Equipment Identity (MEI) :

IE Type: Mobile Equipment Identity (MEI) (75)

IE Length: 8

000. …. = CR flag: 0

…. 0000 = Instance: 0

MEI(Mobile Equipment Identity): 999900000000100

User Location Info (ULI) :

IE Type: User Location Info (ULI) (86)

IE Length: 13

000. …. = CR flag: 0

…. 0000 = Instance: 0

…1 …. = ECGI Present Flag): True

…. 1… = TAI Present Flag): True

…. .0.. = RAI Present Flag): False

…. ..0. = SAI Present Flag): False

…. …0 = CGI Present Flag): False

Mobile Country Code (MCC): Romania (226)

Mobile Network Code (MNC): Orange Romania (10)

Tracking Area Code: 4113

Mobile Country Code (MCC): Romania (226)

Mobile Network Code (MNC): Orange Romania (10)

ECI (E-UTRAN Cell Identifier): 0

Serving Network :

IE Type: Serving Network (83)

IE Length: 3

000. …. = CR flag: 0

…. 0000 = Instance: 0

Mobile Country Code (MCC): Romania (226)

Mobile Network Code (MNC): Orange Romania (10)

RAT Type :

IE Type: RAT Type (82)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

RAT Type: EUTRAN (6)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 1010 = Interface Type: S11 MME GTP-C interface (10)

TEID/GRE Key: 3300033

F-TEID IPv4: 30.0.1.1 (30.0.1.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0001 = Instance: 1

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0111 = Interface Type: S5/S8 PGW GTP-C interface (7)

TEID/GRE Key: 0

F-TEID IPv4: 20.0.0.1 (20.0.0.1)

PDN Type :

IE Type: PDN Type (99)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. .001 = PDN Type: IPv4 (1)

Selection Mode :

IE Type: Selection Mode (128)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. ..00 = Selection Mode: MS or network provided APN, subscribed verified (0)

PDN Address Allocation (PAA) :

IE Type: PDN Address Allocation (PAA) (79)

IE Length: 5

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. .001 = PDN Type: IPv4 (1)

PDN IPv4: 0.0.0.0 (0.0.0.0)

Indication :

IE Type: Indication (77)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

0… …. = DAF (Dual Address Bearer Flag): False

.0.. …. = DTF (Direct Tunnel Flag): False

..0. …. = HI (Handover Indication): False

…0 …. = DFI (Direct Forwarding Indication): False

…. 0… = OI (Operation Indication): False

…. .0.. = ISRSI (Idle mode Signalling Reduction Supported Indication): False

…. ..0. = ISRAI (Idle mode Signalling Reduction Activation Indication): False

…. …0 = SGWCI (SGW Change Indication): False

…. 0… = PT (Protocol Type): False

…. .0.. = TDI (Teardown Indication): False

…. ..0. = SI (Scope Indication): False

…. …0 = MSV (MS Validated): False

Access Point Name (APN) :

IE Type: Access Point Name (APN) (71)

IE Length: 18

000. …. = CR flag: 0

…. 0000 = Instance: 0

APN (Access Point Name): visited.com

APN Restriction :

IE Type: APN Restriction (127)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

APN Restriction: 0

Aggregate Maximum Bit Rate (AMBR) :

IE Type: Aggregate Maximum Bit Rate (AMBR) (72)

IE Length: 8

000. …. = CR flag: 0

…. 0000 = Instance: 0

AMBR Uplink (Aggregate Maximum Bit Rate for Uplink): 1

AMBR Downlink(Aggregate Maximum Bit Rate for Downlink): 1

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 31

000. …. = CR flag: 0

…. 0000 = Instance: 0

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0101 = EPS Bearer ID (EBI): 5

Bearer Level Quality of Service (Bearer QoS) :

IE Type: Bearer Level Quality of Service (Bearer QoS) (80)

IE Length: 22

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. …1 = PVI (Pre-emption Vulnerability): True

..00 00.. = PL (Priority Level): 0

.0.. …. = PCI (Pre-emption Capability): False

Label (QCI): 4

Maximum Bit Rate For Uplink: 65536000

Maximum Bit Rate For Downlink: 65536000

Guaranteed Bit Rate For Uplink: 0

Guaranteed Bit Rate For Downlink: 0

Recovery (Restart Counter) :

IE Type: Recovery (Restart Counter) (3)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

Restart Counter: 0

GPRS Tunneling Protocol V2

Create Session Response

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Create Session Response (33)

Message Length: 126

Tunnel Endpoint Identifier: 3300033

Sequence Number: 7660

Spare: 45056

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

PDN Address Allocation (PAA) :

IE Type: PDN Address Allocation (PAA) (79)

IE Length: 5

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. .001 = PDN Type: IPv4 (1)

PDN IPv4: 40.0.0.1 (40.0.0.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 1011 = Interface Type: S11/S4 SGW GTP-C interface (11)

TEID/GRE Key: 1

F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0001 = Instance: 1

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0111 = Interface Type: S5/S8 PGW GTP-C interface (7)

TEID/GRE Key: 1

F-TEID IPv4: 20.0.0.1 (20.0.0.1)

APN Restriction :

IE Type: APN Restriction (127)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

APN Restriction: 0

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 63

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0101 = EPS Bearer ID (EBI): 5

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)

TEID/GRE Key: 33

F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0001 = Instance: 1

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0101 = Interface Type: S5/S8 PGW GTP-U interface (5)

TEID/GRE Key: 33

F-TEID IPv4: 20.0.0.1 (20.0.0.1)

Bearer Level Quality of Service (Bearer QoS) :

IE Type: Bearer Level Quality of Service (Bearer QoS) (80)

IE Length: 22

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. …0 = PVI (Pre-emption Vulnerability): False

..00 00.. = PL (Priority Level): 0

.0.. …. = PCI (Pre-emption Capability): False

Label (QCI): 9

Maximum Bit Rate For Uplink: 8640000

Maximum Bit Rate For Downlink: 8640000

Guaranteed Bit Rate For Uplink: 0

Guaranteed Bit Rate For Downlink: 0

Recovery (Restart Counter) :

IE Type: Recovery (Restart Counter) (3)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

Restart Counter: 0

 

GPRS Tunneling Protocol V2

Modify Bearer Request

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Modify Bearer Request (34)

Message Length: 30

Tunnel Endpoint Identifier: 1

Sequence Number: 7660

Spare: 45568

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 18

000. …. = CR flag: 0

…. 0000 = Instance: 0

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0101 = EPS Bearer ID (EBI): 5

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0000 = Interface Type: S1-U eNodeB GTP-U interface (0)

TEID/GRE Key: 33

F-TEID IPv4: 30.0.0.1 (30.0.0.1)

 

GPRS Tunneling Protocol V2

Modify Bearer Response

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Modify Bearer Response (35)

Message Length: 42

Tunnel Endpoint Identifier: 3300033

Sequence Number: 7660

Spare: 45568

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 24

000. …. = CR flag: 0

…. 0000 = Instance: 0

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0101 = EPS Bearer ID (EBI): 5

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)

TEID/GRE Key: 33

F-TEID IPv4: 30.0.2.1 (30.0.2.1)

 

GPRS Tunneling Protocol V2

Create Bearer Request

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Create Bearer Request (95)

Message Length: 86

Tunnel Endpoint Identifier: 3300033

Sequence Number: 0

Spare: 256

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0101 = EPS Bearer ID (EBI): 5

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 69

000. …. = CR flag: 0

…. 0000 = Instance: 0

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0000 = EPS Bearer ID (EBI): 0

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)

TEID/GRE Key: 34

F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0001 = Instance: 1

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0101 = Interface Type: S5/S8 PGW GTP-U interface (5)

TEID/GRE Key: 34

F-TEID IPv4: 20.0.0.1 (20.0.0.1)

EPS Bearer Level Traffic Flow Template (Bearer TFT) :

IE Type: EPS Bearer Level Traffic Flow Template (Bearer TFT) (84)

IE Length: 8

000. …. = CR flag: 0

…. 0000 = Instance: 0

001. …. = Operation Code: Create New TFT (1)

…. 0001 = Number of Packet Filters: 1

…0 …. = Ebit: False

Packet Filter 1

…. 0010 = Packet Filter Identifier: 2

..11 …. = Direction: bidirectional (3)

Evaluation Precedence: 2

Length of Packet Filter: 3

Component Type: Single remote port type (5060)

Single remote port type: 5060

Bearer Level Quality of Service (Bearer QoS) :

IE Type: Bearer Level Quality of Service (Bearer QoS) (80)

IE Length: 22

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. …0 = PVI (Pre-emption Vulnerability): False

..01 11.. = PL (Priority Level): 7

.0.. …. = PCI (Pre-emption Capability): False

Label (QCI): 3

Maximum Bit Rate For Uplink: 65535000

Maximum Bit Rate For Downlink: 65535000

Guaranteed Bit Rate For Uplink: 65535000

Guaranteed Bit Rate For Downlink: 65535000

 

GPRS Tunneling Protocol V2

Create Bearer Response

Flags: 72

010. …. = Version: 2

…. 1… = T: 1

Message Type: Create Bearer Response (96)

Message Length: 55

Tunnel Endpoint Identifier: 1

Sequence Number: 0

Spare: 256

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

Bearer Context : [Grouped IE]

IE Type: Bearer Context (93)

IE Length: 37

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause :

IE Type: Cause (2)

IE Length: 2

000. …. = CR flag: 0

…. 0000 = Instance: 0

Cause: Request accepted (16)

…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False

EPS Bearer ID (EBI) :

IE Type: EPS Bearer ID (EBI) (73)

IE Length: 1

000. …. = CR flag: 0

…. 0000 = Instance: 0

…. 0110 = EPS Bearer ID (EBI): 6

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0000 = Instance: 0

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0000 = Interface Type: S1-U eNodeB GTP-U interface (0)

TEID/GRE Key: 34

F-TEID IPv4: 30.0.0.1 (30.0.0.1)

Fully Qualified Tunnel Endpoint Identifier (F-TEID) :

IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)

IE Length: 9

000. …. = CR flag: 0

…. 0001 = Instance: 1

1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True

.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False

…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)

TEID/GRE Key: 34

F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Tags: 4G, Diameter, eNodeB, EPC, HSS, I-CSCF, IMS, loose routing, LTE, MME, P-CSCF, passion, PCRF, PGW, Register, S-CSCF, SGW, strict routing, techie, UE