Flexi Network Gateway Rel. 10 CD8, Operating Documentation, v. 1

Flexi Network Gateway Rel.
10
CD8, Operating
Documentation, v. 1
Session Management Reference Guide
DN0822654
Issue 1-4
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2011/6/29. All rights reserved
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources
of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle
this product and only after having carefully read the safety information applicable to this
product.
The safety information is provided in the Safety Information section in the “Legal, Safety
and Environmental Information” part of this document or documentation set.
The same text in German:
f Wichtiger Hinweis zur Produktsicherheit

Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder
andere Gefahrenquellen ausgehen.
Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch
geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-
anforderungen erfolgen.
Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,
Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-
satzes.
2 Id:0900d8058088cac0
DN0822654 Issue 1-4
Table of Contents
This document has 89 pages.
1 Changes in Flexi NG Session Management Reference Guide . . . . . . . . 9

1.1 Changes between release 10 CD5.2 and release 10CD8 . . . . . . . . . . . . 9
1.2 Changes between release 10 CD4 and release 10 CD5.2 . . . . . . . . . . 10
1.3 Changes between release 10 CD2 and release 10 CD4 . . . . . . . . . . . . 10
1.4 Changes in release 10 CD2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Session management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Session profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 S-GW profiles in session management . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Session profiles in session management. . . . . . . . . . . . . . . . . . . . . . . . 15
4 Session management in GGSN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Primary PDP context messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 GGSN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Session creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 Session deletion initiated from access network . . . . . . . . . . . . . . . . . . . 19
4.2.4 Session deletion initiated from GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Session update initiated from access network. . . . . . . . . . . . . . . . . . . . 22
4.2.6 Session update initiated from PCRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Secondary PDP context messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 Session creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2 Session deletion initiated from access network . . . . . . . . . . . . . . . . . . . 25
4.3.3 Session deletion initiated from GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4 Session update initiated from access network. . . . . . . . . . . . . . . . . . . . 26
5 Session management in S-GW with PMIP variant. . . . . . . . . . . . . . . . . 28

5.1 Interfaces of S-GW with PMIP variant . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Session creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Session deletion initiated from access network . . . . . . . . . . . . . . . . . . . 29
5.4 Session deletion initiated from P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 Session modification initiated from access network. . . . . . . . . . . . . . . . 31
5.6 Session modification initiated from PCRF . . . . . . . . . . . . . . . . . . . . . . . 32
5.7 S-GW relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8 S1 release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.9 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6 Session management in S-GW with GTP variant . . . ...... ........ 36

6.1 Interfaces of S-GW with GTP variant. . . . . . . . . . . . . ...... ........ 36
6.2 Session creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... ........ 36
6.3 Session deletion initiated from access network . . . . . ...... ........ 37
6.4 Session deletion initiated from P-GW . . . . . . . . . . . . ...... ........ 38
6.5 Session modification from access network . . . . . . . . ...... ........ 39
Id:0900d8058088cac0 3
DN0822654 Issue 1-4
6.6 Session modification initiated from P-GW. . . . . . . . . . . . . . . . . . . . . . . . 40

6.7 S-GW relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.8 S1 release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.9 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Session management in P-GW with PMIP variant . . . . . . . . . . . . . . . . . 44

7.1 Interfaces of P-GW with PMIP variant . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2 Session creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Session deletion initiated from S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.4 Session deletion initiated from P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.5 Session modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.6 S-GW relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8 Session management in P-GW with GTP variant . . . . . . . . . . . . . . . . . . 50

8.1 Interfaces of P-GW with GTP variant . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.4 Session deletion initiated from P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5 Session modification initiated from access network . . . . . . . . . . . . . . . . 54
8.6 Session modification initiated from PCRF. . . . . . . . . . . . . . . . . . . . . . . . 55
8.7 S-GW relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9 Session management in combined S-GW and P-GW with PMIP variant 57
10 Session management in combined S-GW and P-GW with GTP variant. 58

10.1 Interfaces of combined S-GW and P-GW with GTP variant . . . . . . . . . . 58
10.4 Session deletion initiated from combined S-GW and P-GW . . . . . . . . . . 61
10.5 Session modification initiated from access network . . . . . . . . . . . . . . . . 62
10.6 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11 Session management in combined S-GW and P-GW with Gn interface 64

11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
11.2 Interfaces of combined S-GW and P-GW . . . . . . . . . . . . . . . . . . . . . . . . 64
11.5 Session deletion initiated from combined S-GW and P-GW . . . . . . . . . . 66
11.6 Session handover from Gn interface to S11 interface . . . . . . . . . . . . . . 66
11.7 Session handover from S11 interface to Gn interface . . . . . . . . . . . . . . 67
11.8 Session handover from S5 interface to Gn interface . . . . . . . . . . . . . . . 69
11.9 Session handover from Gn interface to S5 interface . . . . . . . . . . . . . . . 71
12 Path management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12.2 GTP-C based restart procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.3 Echo Request and Echo Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.3.1 Information elements in an Echo Response message . . . . . . . . . . . . . . 75
12.3.2 Echo Request and Echo Response configuration parameters . . . . . . . . 76
12.3.3 Recovery information element in other PDP contexts/EPS Bearers. . . . 76
4 Id:0900d8058088cac0
DN0822654 Issue 1-4
13 Indirect data forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
14 Idle state signaling reduction (ISR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

14.1 ISR activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
14.2 ISR deactivation with a Delete Session Request without PDN connection
release and peer CN node notification. . . . . . . . . . . . . . . . . . . . . . . . . . 79
14.3 ISR deactivation with a Delete Session Request with PDN connection re-
lease and peer CN node notification . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
14.4 ISR deactivation with a Modify Bearer Request. . . . . . . . . . . . . . . . . . . 81
14.5 ISR deactivation triggered by a Create Session Request . . . . . . . . . . . 82
14.6 HSS-initiated detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
15 Multiple PDN connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

15.1 Access point usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
15.2 Aggregate maximum bit rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
16 Collision handling in session management . . . . . . . . . . . . . . . . . . . . . . 85

16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
16.2 Collision during PDP context procedures . . . . . . . . . . . . . . . . . . . . . . . 86
16.2.1 PDP context activation procedure collisions . . . . . . . . . . . . . . . . . . . . . 86
16.2.2 PDP context deactivation procedure collisions . . . . . . . . . . . . . . . . . . . 86
16.2.3 Network initiated PDP context deactivation procedure collisions . . . . . 87
16.2.4 Update PDP context request collisions . . . . . . . . . . . . . . . . . . . . . . . . . 87
17 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Id:0900d8058088cac0 5
DN0822654 Issue 1-4
List of Figures
Figure 1 Properties related to sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 2 Profiles linked to S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 3 Session profile role in session creation. . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 4 Interfaces of GGSN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 5 Session creation in GGSN (primary PDP context) . . . . . . . . . . . . . . . . . 18
Figure 6 Session deletion initiated from access network . . . . . . . . . . . . . . . . . . . 20
Figure 7 Session deletion initiated from GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 8 Session update initiated from access network . . . . . . . . . . . . . . . . . . . . 22
Figure 9 Session update initiated from PCRF. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 10 Session creation in GGSN (secondary PDP context) . . . . . . . . . . . . . . . 24
Figure 11 Session deletion initiated from access network . . . . . . . . . . . . . . . . . . . 25
Figure 12 Session deletion initiated from GGSN . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 13 Session update initiated from access network . . . . . . . . . . . . . . . . . . . . 26
Figure 14 Interfaces of S-GW with PMIP variant . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 15 Session creation in S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 16 Session deletion initiated from access network in S-GW . . . . . . . . . . . . 30
Figure 17 Session deletion initiated from P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 18 Session modification initiated from access network . . . . . . . . . . . . . . . . 31
Figure 19 Session modification initiated from PCRF. . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 20 S-GW relocation for the default bearer . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 21 S1 release procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 22 Paging in S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 23 S-GW interfaces with GTP variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 24 Session creation in S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 25 Session deletion initiated from access network in S-GW . . . . . . . . . . . . 38
Figure 26 Session deletion initiated from P-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 27 Session modification based on Modify Bearer Request . . . . . . . . . . . . . 39
Figure 28 Signaling related to Modify Bearer Command message. . . . . . . . . . . . . 40
Figure 29 Session modification initiated from P-GW. . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 30 Handovers where Create Session Request triggers Modify Bearer Request
41
Figure 31 S-GW relocation for the default bearer . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 32 P-GW interfaces with PMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 33 Session creation procedure in PMIP-variant P-GW . . . . . . . . . . . . . . . . 45
Figure 34 Session deletion initiated from S-GW . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 35 Session deletion procedure initiated from P-GW . . . . . . . . . . . . . . . . . . 47
Figure 36 Session modification initiated from the access network . . . . . . . . . . . . . 48
Figure 37 S-GW relocation procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 38 P-GW interfaces with GTP variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 39 Session creation in GTP-variant P-GW . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 40 Session deletion initiated from access network in GTP-variant P-GW . . 52
Figure 41 Session deletion initiated from GTP-variant P-GW . . . . . . . . . . . . . . . . . 53
Figure 42 Session modification initiated from access network in GTP-variant P-GW.
54
Figure 43 Session modification initiated from access network, signaling related to the
Modify Bearer Command message in GTP-variant P-GW . . . . . . . . . . . 54
6 Id:0900d8058088cac0
DN0822654 Issue 1-4
Figure 44 Session modification initiated from PCRF, GTP-variant P-GW . . . . . . . 55

Figure 45 S-GW relocation procedure, GTP-variant P-GW . . . . . . . . . . . . . . . . . . 56
Figure 46 Combined S-GW and P-GW interfaces with GTP variant . . . . . . . . . . . 58
Figure 47 Session creation in combined S-GW and P-GW . . . . . . . . . . . . . . . . . . 59
Figure 48 Session deletion initiated from access network in combined S-GW and P-
GW. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figure 49 Session deletion initiated from combined S-GW and P-GW . . . . . . . . . 61
Figure 50 Session modification initiated from access network. . . . . . . . . . . . . . . . 62
Modify Bearer Command message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 52 Interfaces of combined S-GW and P-GW . . . . . . . . . . . . . . . . . . . . . . . 64
Figure 53 Session creation in combined S-GW and P-GW . . . . . . . . . . . . . . . . . . 65
Figure 54 Session deletion initiated from access network (combined S-GW and P-
GW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 55 Session deletion initiated from combined S-GW and P-GW . . . . . . . . . 66
Figure 56 Session handover from Gn interface to S11 interface . . . . . . . . . . . . . . 67
Figure 57 Session handover from S11 interface to Gn interface . . . . . . . . . . . . . . 68
Figure 58 Session handover from S5 interface to Gn interface . . . . . . . . . . . . . . . 70
Figure 59 Session handover from Gn interface to S5 interface . . . . . . . . . . . . . . . 71
Figure 60 Path management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 61 Data path during a handover procedure with S-GW relocation . . . . . . . 77
Figure 62 Indirect data forwarding message flow . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 63 ISR activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 64 ISR deactivation with a Delete Session Request without PDN connection
release and peer CN node notification. . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 65 ISR deactivation with a Delete Session Request with PDN connection re-
lease and peer CN notification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 66 ISR deactivation with Modify Bearer Request . . . . . . . . . . . . . . . . . . . . 82
Figure 67 ISR deactivation with a Create Session Request . . . . . . . . . . . . . . . . . 82
Figure 68 HSS-initiated detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 69 Collision handling in session management . . . . . . . . . . . . . . . . . . . . . . 85
Id:0900d8058088cac0 7
DN0822654 Issue 1-4
List of Tables
Table 1 Separate configuration profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 2 PDP context activation procedure collisions . . . . . . . . . . . . . . . . . . . . . 86
Table 3 PDP context deactivation procedure collisions . . . . . . . . . . . . . . . . . . . 86
Table 4 Network initiated PDP context deactivation procedure collisions . . . . . 87
Table 5 Update PDP context request collisions . . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 6 Session management glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8 Id:0900d8058088cac0
DN0822654 Issue 1-4
Session Management Reference Guide Changes in Flexi NG Session Management Reference
Guide
1 Changes in Flexi NG Session Management

Reference Guide
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
1.1 Changes between release 10 CD5.2 and release 10CD8

Changes between issues 1-3 and 1-4
Chapter About this document: removed the word ‘feature’.
Chapter Session management overview:
• Added information about secondary PDP context support.
Chapter Session management in GGSN:
• Added DHCPv4 messages to session creation and deletion for primary PDP con-
texts.
• Added descriptions for secondary PDP context message flows and divided the
content into primary PDP context and secondary PDP context sections.
• Modified the section Session deletion initiated from access network.
• Modidied the section Session deletion initiated from GGSN.
• Updated the call flow in the Session update initiated from the PCRF section.
Chapter Session management in S-GW with GTP variant:
• Added the figure Signaling related to Modify Bearer Command message.
• Added a reference to the S1 release section in Session management in S-GW with
PMIP variant.
Chapter Session management in P-GW with PMIP variant:
• Added DHCPv4 messages to session creation and deletion.
• Modified the section Session deletion initiated from S-GW.
• Modified the section Session deletion initiated from P-GW.
• Added note to the sections Session modification and S-GW relocation.
Chapter Session management in P-GW with GTP variant: added DHCPv4 messages to
session creation and deletion.
Chapter Session management in combined S-GW and P-GW with GTP variant:
• Added DHCPv4 messages to session creation and deletion.
• Added Figure Session modification initiated from access network, signaling related
to the Modify Bearer Command message.
Chapter Idle state signaling reduction (ISR): Corrected the message names in the figure
ISR deactivation with a Delete Session Request with PDN connection release and peer
CN notification.
Chapter Session management in combined S-GW and P-GW with Gn interface:
• Updated the section Session handover from S11 interface to Gn interface
• Added sections Session handover from S5 interface to Gn interface and Session
handover from Gn interface to S5 interface.
Id:0900d8058088cb87 9
DN0822654 Issue 1-4
Changes in Flexi NG Session Management Reference Session Management Reference Guide
Guide
1.2 Changes between release 10 CD4 and release 10 CD5.2

Chapter Session management in GGSN: Updated the call flow in the Session update
initiated from PCRF section.
1.3 Changes between release 10 CD2 and release 10 CD4

New chapters added:
• Session management in S-GW with GTP variant
• Session management in combined S-GW and P-GW with GTP variant
• Session management in combined S-GW and P-GW with Gn interface
• Idle state signaling reduction (ISR)
• Multiple PDN connections
Chapter Session management overview :
• Added information about PMIP variant.
• Added information about default EPS bearers.
• Added information about support of S-GW and combined S-GW and P-GW (without
GTP S5 interface) modes.
Chapter: Session management in S-GW with PMIP variant: Added the information that
only one default bearer per APN is supported.
Chapter: Session management in P-GW with PMIP variant: Added the information that
only one default bearer per APN is supported.
Chapter: Session management in combined S-GW and P-GW with PMIP variant: Added
the information that only one default bearer per APN is supported.
1.4 Changes in release 10 CD2

The session management content was previously in the Flexi NG User Guide. The fol-
lowing chapters have been moved to this document:
• Session management in S-GW with PMIP variant
• Session management in P-GW with PMIP variant
• Session management in combined S-GW and P-GW with PMIP variant
• Session management in GGSN
• Indirect data forwarding
Changes between User Guide 1-1 and Session Management 1-0

Chapter Session management overview :
• Term ‘deployment option’ replaced with ‘mode.
• Added information about Alias APN and Service awareness profile to section
Session profiles in session management..
Chapter Configuring session profiles:
• Term ‘deployment option’ replaced with ‘mode’.
10 Id:0900d8058088cb87
DN0822654 Issue 1-4
Session Management Reference Guide Changes in Flexi NG Session Management Reference
Guide
• Corrected the value range of parameter session-timeout and added the default
value.
Chapter Session Management in combined S-GW and P-GW: The term ‘SAE-GW’
replaced with ‘combined S-GW and P-GW’.
Chapter Configuring S-GW profiles : corrected the value range of parameter session-
timeout and added the default value.
New chapter added: Collision handling in session management
Chapter : Collisions during PDP context procedures is removed and added as a section
in chapter Collision handling in session management
New chapter added: Path management
• Term ‘SGSN’ is replaced with ‘SGSN/MME’.
• Term ‘GGSN’ is replaced with ‘NG’.
• Term ‘PDP context ‘is replaced with ‘PDP context/EPS bearer’.
• New section added: PMIP S5 path management
Chapter: Session management overview:
• In Gx profile, updated the description.
• Added the information on Tunneling profile.
New chapter added: Glossary
Chapter Session modification based on Create Session Request is removed
Chapter : Session management in S-GW with PMIP variant: added S1 release
Chapter: Indirect data forwarding is removed and moved to Session Management
chapter in Flexi NG User Guide.
Chapter Indirect data forwarding is added and moved from Session Management
chapter in Flexi NG User Guide.
Id:0900d8058088cb87 11
DN0822654 Issue 1-4
About this document Session Management Reference Guide
2 About this document

This document describes the session management in Flexi Network Gateway Release
10 (Flexi NG).
2.1 Scope
This document includes information about the Session management of Flexi NG, which
allows creating, maintaining and deleting end-user sessions connected to packet data
networks (PDN).
2.2 Audience
The intended audience consists of operator network administrators. The audience must
be familiar with the configuration of long-term evolution (LTE) and 3G networks.
12 Id:0900d80580897954
DN0822654 Issue 1-4
Session Management Reference Guide Session management overview
3 Session management overview

Session management allows creating, maintaining, and deleting PDN connections and
EPS bearers/PDP contexts within packet data networks (PDN) connections.
Each PDN connection has a unique APN and IP address combination. EPS bear-
ers/PDP contexts sharing the same IP address and APN belong to same PDN connec-
tion. Multiple PDN connections per one UE is supported. Flexi NG supports up to eleven
EPS bearers/PDP contexts per UE.
In the Gateway GPRS Support Node (GGSN) mode, Flexi NG supports multiple PDN
connections (primary PDP contexts) per UE, and secondary PDP contexts within the
PDN connection. Each primary PDP context has a unique APN and IP address combi-
nation. The IP address is IPv4 or IPv6, and thus IPv4 and IPv6 PDP contexts can be
used.
The GGSN mode supports up to 11 PDP contexts per end user (including at least one
primary PDP context and up to 10 secondary PDP contexts).
In case of Gn interface, the secondary PDP contexts are supported. However, in this
release the dedicated bearers are not supported.
Flexi NG supports GERAN, UTRAN, and E-UTRAN and trusted non 3GPP access over
S2a interface.
For more information on configurations related to session management, see Session
Management in Flexi NG User Guide.
3.1 Session profiles

When the PDN connection is activated, the access point(AP) communicates with a pre-
configured session profile in Flexi NG. The session profile defines the PDN connection’s
properties required in P-GW or GGSN, such as the charging and authentication applied
to PDN connection. The session profile defines the connection’s properties, such as the
charging and authentication applied to it. The following figure illustrates the properties
related to sessions:
Id:0900d8058088d3ee 13
DN0822654 Issue 1-4
Session management overview Session Management Reference Guide
Figure 1 Properties related to sessions

The session properties are managed in a session profile that separately links, for
example, charging and accounting profiles to the session.
3.2 S-GW profiles in session management

When the PDN connection is activated, the pre-configured S-GW profile defines the
PDN connection’s properties required in S-GW, such as session timeouts or access
restrictions applied to the PDN connection. The S-GW profile is applicable when Flexi
NG acts as a standalone S-GW or combined S-GW and P-GW. The following figure illus-
trates the main properties related to S-GW profile:
Figure 2 Profiles linked to S-GW
14 Id:0900d8058088d3ee
DN0822654 Issue 1-4
Session Management Reference Guide Session management overview
t The Gxc profile is relevant only with IETF variant (i.e, S5 (PMIP)).
. For instructions, see Configuring S-GW profiles in Flexi NG User Guide.
3.3 Session profiles in session management

The sessions created for subscriber connections are managed by configuring their pro-
files. The session profile is a collection of settings that defines the session characteris-
tics in Flexi NG, and is selected using an APN. The session profile divides the different
configuration areas, such as authentication and charging, into separate configuration
objects (profiles). For example, there are specific profiles for IP address pools, and
specific profiles to configure RADIUS related properties of the session. In addition,
Diameter profile of session profile defines APN-specific configuration related to
Diameter based Gxc, Gx and Gy interfaces. These separate profiles are linked to the
session profile as needed. Multiple session profiles can use the same configuration pro-
files, thus removing the need for duplicate configuration.
The session profile can also be configured by using Alias APN, which means that
several APNs can be linked to a single session profile. This way any configuration
changes in that session profile affect all the linked APNs simultaneously.
The following figure illustrates the role of the session profile in session creation:
Figure 3 Session profile role in session creation

The session profile itself is directly used only to configure certain general parameters,
for example, the used DNS servers and the delay before deactivating inactive sessions.
Other session properties, such as charging and authentication, are defined in separate
configuration profiles that are linked to session profiles as needed.
The table below lists the configuration profiles that can be linked to session profiles:
Id:0900d8058088d3ee 15
DN0822654 Issue 1-4
Session management overview Session Management Reference Guide
Configuration profile Description

Charging profile Defines the charging properties of a session, for example,
the time and volume limits of CDRs and the used online
charging configuration. For more information, see Charging
in Flexi NG User Guide.
Authentication profile Defines the authentication properties of a session, for
example, the primary and secondary RADIUS servers and
user name settings. For more information, see Authentica-
tion, authorization, and accounting (AAA) in Flexi NG User
Guide.
Accounting profile Defines the accounting properties of a session, for example,
the primary and secondary RADIUS servers and interim
accounting. For more information, see Authentication,
authorization, and accounting (AAA) in Flexi NG User
Guide.
Disconnect profile Defines the disconnect properties of a session, for example,
the RADIUS server. For more information, see Authentica-
tion, authorization, and accounting (AAA) in Flexi NG User
Guide.
IP pool Defines the IP pool properties of a session, for example,
routing instances and subnets. For more information, see
IP pools in Flexi NG User Guide.
Gx profile Defines the Diameter properties for a Gx connection of a
session, for example, the IMSI prefix and Diameter servers.
For more information, see Diameter management in Flexi
NG User Guide.
Tunneling profile Defines the tunneling properties for the user plane of the
Gi/SGi interface. Tunneling profile is defined only if the
Gi/SGi interface uses tunneling. For more information, see
Configuring a tunneling profile in Flexi NG User Guide.
Service awareness Selects one of the defined PCC rule bases. For more infor-
profile (default rule- mation, see Service awareness in Flexi NG User Guide.
base)
Table 1 Separate configuration profiles
For instructions on configuring the separate configuration profiles, see the respective
User Guide chapters.
16 Id:0900d8058088d3ee
DN0822654 Issue 1-4
Session Management Reference Guide Session management in GGSN
4 Session management in GGSN
4.1 Overview
Session management is a basic GGSN functionality that allows creating, maintaining
and deleting end-user sessions called PDP contexts. Flexi NG as a GGSN supports the
following session management procedures:
• UE-initiated PDP context activation, modification, and deactivation.
• Network-initiated PDP context modification and deactivation.
Flexi NG supports up to 11 PDP contexts per end user (including at least one primary
PDP context and possibly 0-10 secondary PDP contexts).
4.2 Primary PDP context messaging
4.2.1 GGSN interfaces

The following figure shows the GGSN logical interfaces related to session management.
Figure 4 Interfaces of GGSN
4.2.2 Session creation

The following figure illustrates the signaling related to the procedure in which a primary
PDP context is created to the GGSN. In this procedure, only messages that are sent to
or received by the GGSN are displayed.
Id:0900d8058088cac1 17
DN0822654 Issue 1-4
Session management in GGSN Session Management Reference Guide
Figure 5 Session creation in GGSN (primary PDP context)

The session creation procedure in GGSN is as follows:
1. The SGSN sends a Create PDP Context Request message to the GGSN.
2. IP address from GGSN local pool is allocated to the subscriber, if defined so in
session profile configuration.
3. If the Gx interface is enabled, then the GGSN sends a Credit Control Request
message to the PCRF for the policy and charging control signaling.
18 Id:0900d8058088cac1
DN0822654 Issue 1-4
4. The PCRF responds to the Credit Control Request message with a Credit Control
Answer message.
5. If the RADIUS authentication is enabled, then the GGSN sends an Access Request
message to the RADIUS server. This can be done for example to inform AAA server
about the PDP context properties and status, to authenticate the subscriber by AAA
server, to allocate IP address to subscriber by AAA server, to get instructions which
OCS to use, or to get a list of allowed services for this subscriber from AAA server.
6. The RADIUS server responds to the Access Request message with an Access
Accept message, optionally delivering the requested information elements to GGSN
session management.
7. If DHCPv4 address allocation is in use, the GGSN sends a DHCP DISCOVER
message to all the configured DHCP server(s).
8. The DHCP server(s) respond with a DHCP OFFER message.
9. The GGSN sends a DHCP REQUEST to the first DHCP server(s) sending the
DHCP OFFER.
10. The DHCP server(s) returns the address in a DHCP ACK message.
11. If the Gx session is active, and RADIUS server allocated IP address for the session
and the Gx event related to IP address allocation is enabled in the Gx session, then
the GGSN sends another Credit Control Request message over Gx to PCRF, which
informs the PCRF about the allocated IP address.
Answer message. The Gx session is activated.
13. If the online charging is enabled for the PDP context, then the GGSN sends a Credit
Control Request message to the online charging system (OCS).
14. The OCS responds to the Credit Control Request message with a Credit Control
Answer message. The online charging session is created for the PDP context.
15. If the RADIUS accounting is enabled, then the GGSN sends an Accounting Request
START message to the RADIUS server, to inform it about the PDP context proper-
ties and status.
16. The RADIUS server responds to the Accounting Request message with an Account-
ing Response message.
17. The GGSN responds to the Create PDP Context Request message with a Create
PDP Context Response message. Note that if the RADIUS accounting is configured
as optional, the GGSN does not wait for the Accounting Response message.
4.2.3 Session deletion initiated from access network

The following figure illustrates the signaling related to procedure, in which primary PDP
context is deleted from the GGSN. In this procedure, only messages that are either sent
to or received by the GGSN are displayed.
Id:0900d8058088cac1 19
DN0822654 Issue 1-4
Figure 6 Session deletion initiated from access network

The session deletion procedure initiated from access network is as follows:
1. The SGSN sends a Delete PDP Context Request message.
2. If the Gx session is active, then the GGSN sends a Credit Control Request message
to the PCRF for the policy and charging control signaling.
Answer message. The Gx session is terminated.
4. If the online charging session is active, then the GGSN sends a Credit Control
Request message to the OCS for online charging control.
Answer message. The online charging session is terminated.
6. If the RADIUS accounting is enabled, then GGSN sends an Accounting Request
STOP message to the RADIUS server, to inform it that PDP context has been deac-
tivated, and IP address (if it was allocated by AAA server) and other resources allo-
cated for this PDP context can be released for further use.
7. GGSN releases the IP address (if it was allocated from GGSN local pool) and other
resources allocated for this PDP context.
ing Response message. Flexi NG waits for the Accounting Response (Stop)
message for a maximum of 60 seconds before proceeding with the bearer deletion.
9. If DHCPv4 address allocation is in use, the GGSN sends the DHCP RELEASE
message to the DHCPv4 server.
20 Id:0900d8058088cac1
DN0822654 Issue 1-4
10. The GGSN responds to the Delete PDP Context Request message with a Delete
PDP Context Response message. This step can be started before the RADIUS
server responds.
4.2.4 Session deletion initiated from GGSN

The following figure illustrates the signaling related to procedure, in which the GGSN
deletes the primary PDP context. This can happen, for example, due to expiration of
session idle timeout timer. In this procedure, only messages that are either sent to or
received by the GGSN are displayed.
Figure 7 Session deletion initiated from GGSN

The session deletion procedure initiated from GGSN is as follows:
1. If the Gx session is active, the GGSN sends a Credit Control Request message to
the PCRF.
3. If the online charging session is active, the GGSN sends a Credit Control Request
message to the OCS.
Answer message.
Id:0900d8058088cac1 21
DN0822654 Issue 1-4
5. If the RADIUS accounting is enabled, the GGSN sends an Accounting Request

message STOP to the RADIUS server.
6. The GGSN sends a Delete PDP Context Request message to the SGSN.
7. The SGSN responds to the Delete PDP Context Request message with a Delete
PDP Context Response message.
9. If DHCPv4 address allocation is in use, the GGSN sends the DHCP RELEASE
4.2.5 Session update initiated from access network

context is updated to the GGSN. This can happen for example due to Inter-SGSN han-
dover, RAT change, QoS change or Direct Tunnel establishment. In this procedure, only
messages that are either sent to or received by the GGSN are displayed.
Figure 8 Session update initiated from access network

The session update procedure initiated from the access network is as follows:
1. The SGSN sends an Update PDP Context Request message.
2. If the Gx session is active, and the update matches with any of the enabled policy
and charging control event triggers, the GGSN sends a Credit Control Request
message to the PCRF.
Answer message.
22 Id:0900d8058088cac1
DN0822654 Issue 1-4
4. If the online charging session is active and the update matches with any of the
enabled online charging event triggers, the GGSN sends a Credit Control Request
message to the OCS.
Answer message.
6. If the RADIUS interim accounting is enabled and the update procedure takes place
due to Inter-SGSN handover, RAT or QoS change, the GGSN sends an Accounting
Request INTERIM message to the RADIUS server.
7. The GGSN responds to the Update PDP Context Request message with an Update
PDP Context Response message. This step can be executed before the RADIUS
server sends a response.
4.2.6 Session update initiated from PCRF

The following figure illustrates the signaling related to the procedure during which the
PCRF initiates an update of a primary PDP context. Only messages that are either sent
to or received by the GGSN are displayed. This procedure is valid only if there is an
active Gx session related to the primary PDP context.
Figure 9 Session update initiated from PCRF

The procedure during a session update that has been initiated from the PCRF is as
follows:
1. The PCRF sends a Re-Auth Request message to the GGSN.
Id:0900d8058088cac1 23
DN0822654 Issue 1-4
2. If the RAR message updates the QoS of the PDP context, the GGSN sends an
Update PDP Context Request message to the SGSN.
3. The SGSN responds to the GGSN with an Update PDP Context Response
message.
4. If the RADIUS accounting interim is enabled, the GGSN sends an Accounting
Request message INTERIM to the RADIUS server.
5. The RADIUS server responds to the GGSN with an Accounting Response message.
6. The GGSN responds to the Re-Auth Request message with a Re-Auth Answer
message.
7. If the online charging session is active and there is a configured trigger for a change
in QoS (either locally configured or already enabled by the OCS), the GGSN sends
a Credit Control Request message to the OCS.
8. The OCS responds to the GGSN with a Credit Control Answer message.
4.3 Secondary PDP context messaging
4.3.1 Session creation

The following figure illustrates the signaling related to secondary PDP context creation
to the GGSN. Only messages that are sent or received by the GGSN are displayed.
Figure 10 Session creation in GGSN (secondary PDP context)

The session creation procedure in GGSN is as follows:
1. The SGSN sends a Create PDP Context Request message to the GGSN.
2. If RADIUS accounting is enabled, then the GGSN sends an Accounting Request
START message to the RADIUS server, to inform it about the PDP context proper-
ties and status.
4. The GGSN responds to the Create PDP Context Request message with a Create
PDP Context Response message. Note that if the RADIUS accounting is configured
as optional, the GGSN does not wait for the Accounting Response message.
24 Id:0900d8058088cac1
DN0822654 Issue 1-4
4.3.2 Session deletion initiated from access network

The following figure illustrates the signaling related to secondary PDP context deletion
from the GGSN. Only messages that are either sent or received by the GGSN are dis-
played.
Figure 11 Session deletion initiated from access network

The session deletion procedure initiated from access network for secondary PDP
contexts is as follows:
2. If RADIUS accounting is enabled, the GGSN sends an Accounting Request STOP
message to the RADIUS server to inform it that PDP context has been deactivated.
At this point, the IP address (if it was allocated by the AAA server) and other
resources allocated for this PDP context can be released for further use.
3. GGSN releases the IP address (if it was allocated from GGSN local pool) and other
resources allocated for this PDP context.
4. The GGSN responds to the Delete PDP Context Request message with a Delete
PDP Context Response message. This step can be started before the RADIUS
server responds.
ing Response message. Flexi NG waits for the Accounting Response (Stop)
message for a maximum of 60 seconds before proceeding with the bearer deletion.
4.3.3 Session deletion initiated from GGSN

The following figure illustrates the signaling related to secondary PDP context deletion
by GGSN. This can happen, for example, due to the expiration of the session idle
timeout timer. Only messages that are either sent or received by the GGSN are dis-
played.
Id:0900d8058088cac1 25
DN0822654 Issue 1-4
Figure 12 Session deletion initiated from GGSN

The session deletion procedure initiated from GGSN for secondary PDP contexts is as
follows:
1. If RADIUS accounting is enabled, the GGSN sends an Accounting Request
message STOP to the RADIUS server.
2. The GGSN sends a Delete PDP Context Request message to the SGSN.
4.3.4 Session update initiated from access network

context is updated to the GGSN. This can happen for example due to Inter-SGSN han-
dover, RAT change, QoS change or Direct Tunnel establishment. In this procedure, only
messages that are either sent to or received by the GGSN are displayed.
Figure 13 Session update initiated from access network

The session update procedure initiated from the access network for secondary PDP
contexts is as follows:
26 Id:0900d8058088cac1
DN0822654 Issue 1-4
1. The SGSN sends an Update PDP Context Request message.

2. If RADIUS interim accounting is enabled and the update procedure takes place due
to Inter-SGSN handover, RAT or QoS change, the GGSN sends an Accounting
Request INTERIM message to the RADIUS server.
3. The GGSN responds to the Update PDP Context Request message with an Update
PDP Context Response message. This step can be executed before the RADIUS
server sends a response.
Id:0900d8058088cac1 27
DN0822654 Issue 1-4
Session management in S-GW with PMIP variant Session Management Reference Guide
5 Session management in S-GW with PMIP

variant
5.1 Interfaces of S-GW with PMIP variant

The following figure shows the external logical interfaces of the S-GW when PMIP
variant is used.
Figure 14 Interfaces of S-GW with PMIP variant
5.2 Session creation

The following figure illustrates the signaling related to the procedure in which the default
bearer is created in the S-GW. Note that, only one default bearer per APN is supported
with PMIP. In this procedure, only the messages that are either sent to or received by
the serving gateway (S-GW) are displayed. If a S1-U interface is used for user plane for-
warding, the user plane forwarding will be pos-sible only after the bearer modification
procedure has defined the user plane connection.
28 Id:0900d805807929e0
DN0822654 Issue 1-4
Session Management Reference Guide Session management in S-GW with PMIP variant
Figure 15 Session creation in S-GW

The session creation procedure in S-GW is as follows:
1. The mobility management entity (MME) or serving GPRS support node (SGSN)
sends a Create Session Request message to the S-GW.
2. If the Gxc interface is enabled, then the S-GW sends the initial Credit Control
Request message to the policy and charging rule function (PCRF) and the Gxc
session is created for the default bearer.
Answer message.
4. The S-GW sends a Proxy Binding Update message to the packet data network
gateway (P-GW).
5. The P-GW responds to the Proxy Binding Update message with a Proxy Binding
Acknowledgement message.
6. The S-GW completes the session creation procedure and responds to the MME or
the SGSN with a Create Session Response message.
5.3 Session deletion initiated from access network

bearer is deleted in the S-GW from the access network. In this procedure, only the
messages that are either sent to or received by the S-GW are displayed.
Id:0900d805807929e0 29
DN0822654 Issue 1-4
Figure 16 Session deletion initiated from access network in S-GW

1. The MME or the SGSN sends a Delete Session Request message to the S-GW.
2. If the Gxc interface is enabled, then the S-GW sends the final Credit Control
Request message to the PCRF.
Answer message and the related Gxc session is terminated.
4. The S-GW sends a Proxy Binding Update message to the P-GW, which indicates
that the session is to be terminated in the P-GW.
6. The S-GW completes the procedure and responds to the MME/SGSN with a Delete
Session Response message.
5.4 Session deletion initiated from P-GW

bearer is deleted in the S-GW from the P-GW. In this procedure, only the messages that
are either sent to or received by the S-GW are displayed.
30 Id:0900d805807929e0
DN0822654 Issue 1-4
Figure 17 Session deletion initiated from P-GW

The session deletion procedure initiated from P-GW is as follows:
1. The P-GW sends a Binding Revocation Indication (BRI) message to the S-GW.
2. If the Gxc interface is enabled, then the S-GW sends a Credit Control Request
Answer message and the related Gxc session is terminated.
4. The S-GW sends a Delete Bearer Request message to the MME or the SGSN.
5. The MME or the SGSN responds to Delete Bearer Request message with a Delete
Bearer Response message. The Session is terminated from the MME or the SGSN
at this point.
6. The S-GW responds to the BRI with a Binding Revocation Acknowledge (BRA)
message.
5.5 Session modification initiated from access network

bearer is modified to the S-GW, for example RAT change or QoS modification.
Figure 18 Session modification initiated from access network

The session modification initiated from access network is as follows:
Id:0900d805807929e0 31
DN0822654 Issue 1-4
1. The MME or the SGSN sends a Modify Bearer Request message to the combined
S-GW.
2. If the Gxc session is active, the S-GW sends a Credit Control Request message to
the PCRF.
Answer message. message.
4. The S-GW responds to the Modify Bearer Request message with a Modify Bearer
Response message. message.
5.6 Session modification initiated from PCRF

bearer is modified by the PCRF, for example QoS change. In this procedure, only the
messages that are either sent to or received by the S-GW are displayed. The session
modification procedure initiated from PCRF is relevant only in cases where the Gxc
interface is enabled and there is an active Gxc session related to the default bearer.
Figure 19 Session modification initiated from PCRF

The session modification initiated from PCRF is as follows:
1. The PCRF sends a Re-Auth-Request (RAR) message.
2. If the RAR defines modification, which requires signaling with the MME or SGSN,
then the S-GW will send an Update Bearer Request message to the MME or the
SGSN. For more information, see 3GPP 29.274.
3. The MME or the SGSN responds to the Update Bearer Request message with an
Update Bearer Response message.
4. The S-GW responds to the RAR with a Re-Auth-Answer (RAA) message.
5.7 S-GW relocation

The following figure illustrates the signaling related to the procedure in which there is S-
GW relocation for the default bearer. In this procedure, only the messages that are either
sent to or received by the source or the target S-GW are displayed.
32 Id:0900d805807929e0
DN0822654 Issue 1-4
Figure 20 S-GW relocation for the default bearer

The S-GW relocation for the default bearer is as follows:
1. The target MME or SGSN sends a Create Session Request message to the target
S-GW.
2. If the Gxc interface is enabled in the target S-GW, then it sends Credit Control
Request message to PCRF.
Answer message. A Gxc session is created between the target S-GW and the
PCRF.
4. The target S-GW responds to the Create Session Request message with a Create
Session Response mes-sage. If the user plane forwarding is based on S4-U, the S-
GW does not send a Create Session Response message until it receives a Proxy
Binding Acknowledgement message from the P-GW.
5. If the user plane forwarding is based on the S1-U interface, the target MME or SGSN
sends a Modify Bearer Request message to the target S-GW.
6. If the user plane forwarding is based on the S1-U interface, the target S-GW sends
a Proxy Binding Update message to the P-GW after it receives a Modify Bearer
Request message. If the user plane forwarding is based on the S4-U interface, then
the S-GW sends a Proxy Binding Update message after it receives a Credit Control
Answer message from the PCRF in step 3.
Id:0900d805807929e0 33
DN0822654 Issue 1-4
8. The S-GW responds to the Modify Bearer Request message with a Modify Bearer
Response message.
9. The source MME or SGSN sends a Delete Session Request message to the source
S-GW.
10. If the Gxc session is active, then the source S-GW will send a Credit Control
Answer message. The Gxc session between PCRF and the source S-GW is termi-
nated.
12. The source S-GW responds to the Delete Session Request message with a Delete
Session Response mes-sage.
5.8 S1 release
The following figure illustrates the signaling related to the S1 release procedure. In this
procedure only the messages that are sent to or received by the S-GW are displayed.
Figure 21 S1 release procedure

The S1 release procedure in S-GW is as follows:
1. The MME/SGSN sends a Release Access Bearers Request message to the S-GW.
2. The S-GW responds to the Release Access Bearers Request with a Release
Access Bearers Response message.
5.9 Paging
The following figure illustrates the signaling related to the paging procedure. In this pro-
cedure only the messages that are either sent to or received by the S-GW are displayed.
34 Id:0900d805807929e0
DN0822654 Issue 1-4
Figure 22 Paging in S-GW

The paging procedure in S-GW is as follows:
1. The P-GW forwards a downlink user plane packet to the S-GW.
2. If no user plane connection is defined for the downlink packet forwarding in the S-
GW and there is no ongoing paging procedure, then the S-GW sends a Downlink
Data Notification message to the MME or the SGSN.
3. The MME or the SGSN responds to the Downlink Data Notification message with a
Downlink Data Notification Acknowledge message. The paging procedure is com-
pleted after the user plane connection is restored as part of the session modification
procedure. If the paging procedure fails, the MME or the SGSN sends a Downlink
Data Notification Failure message to the S-GW.
Id:0900d805807929e0 35
DN0822654 Issue 1-4
Session management in S-GW with GTP variant Session Management Reference Guide
6 Session management in S-GW with GTP

variant
6.1 Interfaces of S-GW with GTP variant

The following figure shows the logical interface of S-GW with GTP variant
Figure 23 S-GW interfaces with GTP variant

bearer is created in the S-GW. In this procedure, only the messages that are either sent
to or received by the serving gateway (S-GW) are displayed. If an S1-U interface is used
for user plane forwarding, the user plane forwarding is possible only after the bearer
modification procedure defines the user plane connection.
36 Id:0900d80580866ddf
DN0822654 Issue 1-4
Session Management Reference Guide Session management in S-GW with GTP variant
Figure 24 Session creation in S-GW

The session creation procedure in S-GW is as follows:
sends a Create Session Request message to the S-GW.
2. The S-GW sends a Create Session Request message to the packet data network
gateway (P-GW).
3. The P-GW responds with a Create Session Response message to the S-GW.
4. The S-GW responds with a Create Session Response message to the MME or the
SGSN.
5. The MME sends a Modify Bearer Request message to the S-GW, which creates the
user plane connection over the S1-U interface. Note that this step is not executed if
the bearer was created from the SGSN, because the SGSN creates the user plane
connection over the S4-U interface in step 1.
6. The S-GW sends a Modify Bearer Request message to the P-GW (over the S5 inter-
face) only if RAT, Serving Network, ULI, or time zone has changed.
7. The P-GW responds to the S-GW only if step 6 is executed.
8. The S-GW completes the session creation procedure and responds to the MME or
the SGSN with a with Modify Bearer Response message.

bearer is deleted in the S-GW from the access network. In this procedure, only the
Id:0900d80580866ddf 37
DN0822654 Issue 1-4
Figure 25 Session deletion initiated from access network in S-GW

1. The MME or the SGSN sends a Delete Session Request message to the S-GW.
2. The S-GW sends a Delete Session Request message to the P-GW, which indicates
that the session is to be terminated in the P-GW. Note that step 2 is excuted in all
scenarios except for handovers with S-GW relocation.
3. The P-GW responds to the S-GW with a Delete Session Response message only if
step 2 is executed.
4. The S-GW completes the procedure and responds to the MME or the SGSN with a
Delete Session Response message.

bearer is deleted in the S-GW from the P-GW. In this procedure, only the messages that
are either sent to or received by the S-GW are displayed.
Figure 26 Session deletion initiated from P-GW

The session deletion procedure initiated from P-GW is as follows:
1. The P-GW sends a Delete Bearer Request message to the S-GW.
38 Id:0900d80580866ddf
DN0822654 Issue 1-4
2. The S-GW sends a Delete Bearer Request message to the MME or the SGSN.
3. The MME or the SGSN responds to the S-GW with a Delete Bearer Response
message. The Session is terminated from the MME or the SGSN at this point.
4. The S-GW responds to the P-GW with a Delete Bearer Response message.
6.5 Session modification from access network

The following figure illustrates the signaling related to the session modification proce-
dure, for example RAT or QoS change in which the access network sends the Modify
Bearer Request. In this procedure, only messages that are either sent to or received by
the S-GW are displayed.
Figure 27 Session modification based on Modify Bearer Request

The session modification procedure based on the Modify Bearer Request message is
as follows:
1. The MME or the SGSN sends a Modify Bearer Request message to the S-GW.
2. The S-GW sends a Modify Bearer Request message to the P-GW only if RAT,
Serving Network, ULI or time zone has changed.
3. The P-GW responds to the S-GW with a Modify Bearer Response message if the
Modify Bearer Request was sent in step 2.
4. The S-GW responds to the MME or the SGSN with a Modify Bearer Response
message.
Session modification based on the Modify Bearer Request message can occur in the fol-
lowing scenarios:
• E-UTRAN tracking area update without S-GW Change
• Routing area update with MME interaction and without S-GW change
• Inter SGSN routeing area update and combined inter SGSN RA/LA update using S4
• Routeing area update using S4
• Enhanced serving RNS relocation using S4
• UE-triggered service request
• UE-initiated Service Request using S4
• X2-based handover without Serving GW relocation
• S1-based handover without S-GW change
• E-UTRAN to UTRAN Iu mode Inter RAT handover without S-GW change
Id:0900d80580866ddf 39
DN0822654 Issue 1-4
• UTRAN Iu mode to E-UTRAN Inter RAT handover without S-GW change

For more information, see 3GPP TS 23.401
The following figure illustrates the signaling related to the Modify Bearer Command
message.
Figure 28 Signaling related to Modify Bearer Command message

The signaling related to the Modify Bearer Command message is as follows:
1. The MME or the SGSN sends a Modify Bearer Command message to the S-GW.
2. The S-GW forwards the Modify Bearer Command to the P-GW.
3. In an error case, the P-GW responds to the Modify Bearer Command with a Modify
Bearer Failure Indication message to the S-GW.
4. The S-GW forwards the Modify Bearer Failure Indication message to the MME or
SGSN.
5. In a successful case, the P-GW responds to the Modify Bearer Command with a
Update Bearer Request message to the S-GW.
6. The S-GW forwards the Update Bearer Request messag to the MME or SGSN.
7. The SGSN or MME responds to the Update Bearer Request message with a Update
Bearer Response message to the S-GW.
8. The S-GW forwards the Update Bearer Response message to the P-GW.
6.6 Session modification initiated from P-GW

The following figure illustrates the signaling related to the procedure, for example QoS
change in which the default bearer is modified by the P-GW. In this procedure, only the
40 Id:0900d80580866ddf
DN0822654 Issue 1-4
Figure 29 Session modification initiated from P-GW

The session modification procedure initiated from P-GW is as follows:
1. The P-GW sends an Update Bearer Request message to the S-GW.
2. The S-GW sends an Update Bearer Request message to the MME or SGSN.
3. The MME or the SGSN responds to S-GW with an Update Bearer Response
message.
4. The S-GW responds to the P-GW with an Update Bearer Response message.
6.7 S-GW relocation

Handovers where Create Session Request triggers Modify Bearer Request
The following figure illustrates the signaling procedure in which the S-GW triggers
sending the Modify Bearer Request message to the P-GW after receiving the Create
Session Request message. In this procedure, only the messages that are either sent to
or received by the S-GW are displayed..
Figure 30 Handovers where Create Session Request triggers Modify Bearer Request
The procedure for handovers based on the Create Session Request message is as
follows:
Id:0900d80580866ddf 41
DN0822654 Issue 1-4
1. The target MME or the SGSN sends a Create Session Request message to the
target S-GW.
2. The target S-GW sends a Modify Bearer Request message to the P-GW.
3. The P-GW responds to the target S-GW with a Modify Bearer Response message.
4. The target S-GW responds to the MME or the SGSN with a Create Session
Response message.
5. The source MME or the SGSN sends Delete Session Request message to the
source S-GW.
6. The source S-GW responds to the source MME or the SGSN with Delete Session
Response message.
Handovers based on the Create Session Request message can occur in the following
scenarios:
• Tracking area update with S-GW change
• Routing area update with MME interaction and with S-GW change
• X2-based handover with S-GW relocation
• S1-based handover with S-GW change
For more information, see 3GPP TS 23.401.
GW relocation for the default bearer and MME or SGSN sends always Modify Bearer
Request to S-GW. In this procedure, only the messages that are either sent to or
received by the source or the target S-GW are displayed.
Figure 31 S-GW relocation for the default bearer

If the user plane forwarding is based on the S1-U interface, the S-GW relocation proce-
dure for the default bearer is as follows:
1. The target MME sends a Create Session Request message to the target S-GW.
42 Id:0900d80580866ddf
DN0822654 Issue 1-4
3. The target MME sends a Modify Bearer Request message to the target S-GW.
4. The target S-GW sends a Modify Bearer Request message to the P-GW after it
receives a Modify Bearer Request message.
5. The P-GW responds to the Modify Bearer Request message with a Modify Bearer
Response message.
6. The target S-GW responds to the Modify Bearer Request message with a Modify
Bearer Response message.
7. The source MME sends a Delete Session Request message to the source S-GW.
If the user plane forwarding is based on the S4-U interface, the S-GW relocation proce-
dure for the default bearer is as follows:
1. The target SGSN sends a Create Session Request message to the target S-GW.
3. The target SGSN sends a Modify Bearer Request message to the target S-GW.
4. The target S-GW sends a Modify Bearer Request message to the P-GW.
Response message.
6. The target S-GW responds to the Modify Bearer Request message with a Modify
Bearer Response message.
7. The source SGSN sends a Delete Session Request message to the source S-GW.
6.8 S1 release
See chapter 5.8 S1 release in Session management in S-GW with PMIP variant.
6.9 Paging
For more information on paging in S-GW with GTP variant , see Session management
in S-GW with PMIP variant.
Id:0900d80580866ddf 43
DN0822654 Issue 1-4
Session management in P-GW with PMIP variant Session Management Reference Guide
7 Session management in P-GW with PMIP

variant
7.1 Interfaces of P-GW with PMIP variant

The following figure shows the logical interfaces of P-GW with PMIP. Note that it shows
only the interfaces related to session management.
Figure 32 P-GW interfaces with PMIP

The following figure illustrates the signaling related to the procedure in which the session
is created in the P-GW. In this procedure, only messages that are either sent to or
received by the P-GW are displayed.
44 Id:0900d80580899699
DN0822654 Issue 1-4
Session Management Reference Guide Session management in P-GW with PMIP variant
Figure 33 Session creation procedure in PMIP-variant P-GW

The session creation procedure in P-GW is as follows:
1. The S-GW sends a Proxy Binding Update message to the P-GW.
2. If the Gx interface is enabled, then the P-GW sends a Credit Control Request
Answer message. A Gx session is created between the PCRF and the P-GW.
4. If the RADIUS authentication is enabled, then the P-GW sends an Access Request
message to the RADIUS server.
Accept message.
6. If DHCPv4 address allocation is in use, the P-GW sends a DHCP DISCOVER
8. The P-GW sends a DHCP REQUEST to the first DHCP server(s) sending the DHCP
OFFER.
Id:0900d80580899699 45
DN0822654 Issue 1-4

10. If the Gx session is active, the RADIUS server allocated IP address for the session
and the Gx event related to the IP address allocation is enabled in the Gx session,
then the P-GW sends another Credit Control Request message to the PCRF, to
inform the PCRF about the allocated IP address.
Answer message.
12. If RADIUS accounting is enabled, then the P-GW sends an Accounting Request
START message to the RADIUS server.
Acknowledgement message. If RADIUS accounting is configured as optional, the P-
GW does not wait for the Accounting Response message.
7.3 Session deletion initiated from S-GW

The following figure illustrates the signaling related to the procedure in which the S-GW
deletes the session in the P-GW. In this procedure, only messages that are either sent
to or received by the P-GW are displayed.
Figure 34 Session deletion initiated from S-GW

The session deletion procedure initiated from the S-GW is as follows:
1. The S-GW sends a Proxy Binding Update message to the P-GW.
2. If there is an active Gx session, then the P-GW sends a Credit Control Request
4. If the RADIUS accounting is enabled, then the P-GW sends an Accounting Request
STOP message to the RADIUS server.
5. The RADIUS server responds to Accounting Request with Accounting Response.
46 Id:0900d80580899699
DN0822654 Issue 1-4
6. If DHCPv4 address allocation is in use, the P-GW sends the DHCP RELEASE
Acknowledgement message. The session is deleted from the P-GW. Note that the
P-GW sends a Proxy Binding Update message before it receives a response from
the RADIUS server.

The following figure illustrates the signaling related to the procedure in which the P-GW
initiates the session deletion procedure. In this procedure, only messages that are either
sent to or received by the P-GW are displayed. The cases where the procedure is orig-
inally initiated by PCRF or the RADIUS server are described in the related interface
specifications.
Figure 35 Session deletion procedure initiated from P-GW

The session deletion procedure initiated from the P-GW is as follows:
1. If the Gx session is active, the P-GW sends a Credit Control Request message to
the PCRF.
3. If the RADIUS accounting is enabled, then the P-GW sends an Accounting Request
(Stop) message to the RADIUS server.
4. The P-GW sends a BRI to the S-GW. Note that the BRI is sent before the P-GW
receives a response from the RADIUS server.
7. The S-GW responds to the BRI with a BRA. The session is deleted from the S-GW.
Id:0900d80580899699 47
DN0822654 Issue 1-4
7.5 Session modification

The following figure illustrates the signaling related to the session modification initiated
from the access network or PCRF, for example RAT change or QoS modification. In this
procedure, only messages that are either sent to or received by the P-GW are displayed.
Note that in the PMIP variant there is no signaling between the S-GW and the P-GW.
The PCRF modifies the session based on the information received from the S-GW,
which is based on the modification originating from the access network. If a Gx session
is not active in the P-GW, session modifications are not initiated. For more information
on the session modifications that supports RAR message, see Diameter Policy Control
Application.
Figure 36 Session modification initiated from the access network

The procedure for session modification initiated from the access network or PCRF is as
follows:
1. The PCRF sends a RAR to the P-GW.
2. If the RADIUS interim accounting is enabled and the modification matches with any
of the enabled interim accounting trigger events, then the P-GW sends an Account-
ing Request INTERIM message to the RADIUS server.
3. The P-GW responds to the RAR with a RAA. Note that the RAA is sent before the
P-GW receives a response from the RADIUS server.
g Currently, Flexi NG does not support the Accounting Request because of QoS or RAT
changes.
7.6 S-GW relocation

GW relocation for the default bearer. Note that, only one default bearer per APN is sup-
ported with PMIP. In this procedure, only those messages that are either sent to or
received by the P-GW are displayed.
48 Id:0900d80580899699
DN0822654 Issue 1-4
Figure 37 S-GW relocation procedure

1. The Target S-GW sends a Proxy Binding Update message to the P-GW.
2. If the Gx session is active and the S-GW relocation procedure triggers any of the
enabled Gx trigger events, then the P-GW sends a Credit Control Request message
to the PCRF.
Answer message.
4. If the RADIUS interim accounting is enabled and the S-GW relocation procedure
triggers any of the enabled interim accounting trigger events, then the P-GW sends
an Accounting Request INTERIM message to the RADIUS server.
Acknowledgement message. Note that Proxy Binding Acknowledgement message
is sent before the P-GW has received response from the RADIUS server.
6. The RADIUS server responds to Accounting Request message with an Accounting
Response message.
g Currently, Flexi NG does not support the Accounting Request because of S-GW
changes.
Id:0900d80580899699 49
DN0822654 Issue 1-4
Session management in P-GW with GTP variant Session Management Reference Guide
8 Session management in P-GW with GTP

variant
8.1 Interfaces of P-GW with GTP variant

The following figure illustrates the logical interfaces in the GTP-variant P-GW:
Figure 38 P-GW interfaces with GTP variant

bearer is created in the P-GW. In this procedure, only the messages that are either sent
to or received by the P-GW are displayed.
50 Id:0900d80580899f00
DN0822654 Issue 1-4
Session Management Reference Guide Session management in P-GW with GTP variant
Figure 39 Session creation in GTP-variant P-GW

The session creation procedure in GTP-variant P-GW is as follows:
1. The S-GW sends a Create Session Request message to the P-GW.
2. If the Gx interface is enabled, the P-GW sends a Credit Control Request message
over the Gx interface to the PCRF.
Answer message. A Gx session is created.
4. If RADIUS authentication is enabled, the P-GW sends an Access Request message
to the RADIUS server.
Accept message.
6. If DHCPv4 address allocation is in use, the P-GW sends a DHCP DISCOVER
Id:0900d80580899f00 51
DN0822654 Issue 1-4
8. The P-GW sends a DHCP REQUEST to the first DHCP server(s) sending the DHCP
OFFER.
9.The DHCP server(s) returns the address in a DHCP ACK message.
and the Gx event related to IP address allocation is enabled in the Gx session, the P-
GW sends another Credit Control Request message over the Gx interface to the PCRF
and informs the PCRF about the allocated IP address.
11. The PCRF responds to the Credit Control Request message with the Credit Contro-
lAnswer message.
12. If RADIUS accounting is enabled, the P-GW sends Accounting Request message
START to the RADIUS server.
13. The RADIUS server responds to the Accounting Request with an Accounting
Response message.
14. The P-GW responds to the Create Session Request message with a Create Session
Response message. If RADIUS accounting is configured as optional, the P-GW does
not wait for the Accounting Response message.

bearer is deleted from the P-GW. In this procedure, only the messages that are either
sent to or received by the P-GW are displayed.
Figure 40 Session deletion initiated from access network in GTP-variant P-GW

1. The S-GW sends a Delete Session Request message to the P-GW.
2. If the Gx session is active, the P-GW sends a Credit Control Request message over
the Gx interface to the PCRF.
Answer message.
52 Id:0900d80580899f00
DN0822654 Issue 1-4
4. If RADIUS accounting is enabled, the P-GW sends an Accounting Request STOP

ing Response message. Flexi NG waits for the Accounting Response (Stop) message
for a maximum of 60 seconds before proceeding with the bearer deletion.
7. The P-GW responds to the Delete Session Request message with a Delete Session
Response message. Note that the PGW does not wait for the Accounting Response
message.

The following figure illustrates the signaling related to the procedure in which the
combined P-GW deletes the default bearer. In this procedure, only the messages that
are either sent to or received by the P-GW are displayed.
Figure 41 Session deletion initiated from GTP-variant P-GW

The session deletion procedure initiated fromGTP-variant P-GW is as follows:
1. If the Gx session is active, the P-GW sends a Credit Control Request message over
the Gx interface to the PCRF.
Answer message.
3. If RADIUS accounting is enabled, the P-GW sends an Accounting Request STOP
4. The P-GW sends a Delete Bearer Request message to the S-GW. Note that the P-
GW does not wait for an Accounting Response message from the RADIUS server.
5. The S-GW responds to the Delete Bearer Request message with a Delete Bearer
Response message.
Id:0900d80580899f00 53
DN0822654 Issue 1-4

bearer is modified to the GTP-variant P-GW:
Figure 42 Session modification initiated from access network in GTP-variant P-GW

The session modification procedure initiated from access network in the GTP-variant P-
GW is as follows:
1. The S-GW sends a Modify Bearer Request message to the P-GW.
2. If the Gx session is active, and if the session modification matches any of the enabled
Gx trigger events, the P-GW sends a Credit Control Request message to the PCRF.
Answer message.
Response message.
message in the GTP-variant P-GW:
Modify Bearer Command message in GTP-variant P-GW
1. TheS-GW sends a Modify Bearer Command message to the P-GW.
2.a In an error case, the P-GW responds to the Modify Bearer Command message with
a Modify Bearer Failure Indication message.
54 Id:0900d80580899f00
DN0822654 Issue 1-4
2.b In a successful case, the P-GW responds to the Modify Bearer Command message
with an Update Bearer Request message.
3. The S-GW responds to the Update Bearer Request message with an Update Bearer
Response message.
8.6 Session modification initiated from PCRF

The following figure illustrates the signaling related to the procedure in which the PCRF
initiates default bearer modification. In this procedure, only messages that are either
sent to or received by the P-GW are displayed. This procedure is possible only when the
Gx interface is enabled and the Gx session related to the modified default bearer is
active.
Figure 44 Session modification initiated from PCRF, GTP-variant P-GW

The session modification initiated from PCRF is as follows
1. The PCRF sends a RAR message to the P-GW.
2. If RADIUS interim accounting is enabled and the modification matches with any of the
enabled interim accounting trigger events, then the P-GW sends an Accounting Request
INTERIM message to the RADIUS server.
3. If the RAR modifies the QoS of the session, the P-GW sends an Update Bearer
Request message to the S-GW.
4. The S-GW responds to the Update Bearer Request message with an Update Bearer
Response message.
5. The P-GW responds to the RAR with a RAA message. Note that the P-GW does not
wait for Accounting Response message fromthe RADIUS server.
g Currently, Flexi NG does not support the Accounting Request because of QoS or RAT
changes.
Id:0900d80580899f00 55
DN0822654 Issue 1-4
8.7 S-GW relocation

The following figure illustrates the signaling related to the S-GW relocation procedure.
In this procedure, only the messages that are either sent to or received by the P-GW are
displayed.
Figure 45 S-GW relocation procedure, GTP-variant P-GW

1. The Target S-GW sends a Modify Bearer Request message to the P-GW.
2. If the Gx session is active and the S-GW relocation procedure triggers any of the
enabled Gx trigger events, then the P-GW sends a Credit Control Request message to
the PCRF.
Answer message.
4. If RADIUS interim accounting is enabled and the S-GW relocation procedure triggers
any of the enabled interim accounting trigger events, then the P-GW sends an Account-
ing Request INTERIM message to the RADIUS server.
Response message. Note that the Modify Bearer Reponse message is sent before the
P-GW has received response from the RADIUS server.
g Currently, Fexi NG does not support the Accounting Request beacuse of P-GW
changes.
56 Id:0900d80580899f00
DN0822654 Issue 1-4
Session Management Reference Guide Session management in combined S-GW and P-GW
with PMIP variant
9 Session management in combined S-GW and

P-GW with PMIP variant
In the combined S-GW and P-GW mode, Flexi NG acts according to S-GW and P-GW
sequences but without the S5 signaling.
g Only one default bearer per APN is supported with PMIP.
Id:0900d80580792665 57
DN0822654 Issue 1-4
Session management in combined S-GW and P-GW Session Management Reference Guide
with GTP variant

P-GW with GTP variant
10.1 Interfaces of combined S-GW and P-GW with GTP variant

The following figure shows the logical interface of combined S-GW and P-GW with GTP
variant.
Figure 46 Combined S-GW and P-GW interfaces with GTP variant

bearer is created in thecombined S-GW and P-GW. In this procedure, only the
messages that are either sent to or received by the combined S-GW and P-GW are dis-
played.
58 Id:0900d8058089fd45
DN0822654 Issue 1-4
with GTP variant
Figure 47 Session creation in combined S-GW and P-GW

The session creation procedure in combined S-GW and P-GW is as follows:
sends a Create Session Request message to the combined S-GW and P-GW.
2. If the Gx interface is enabled, the combined S-GW and P-GW sends a Credit Control
Request message over the Gx interface to the PCRF.
Answer message. A Gx session is created.
4. If RADIUS authentication is enabled, the combined S-GW and P-GW sends an
Access Request message to the RADIUS server.
Accept message.
6. If DHCPv4 address allocation is in use, the combined S-GW and P-GW sends a
DHCP DISCOVER message to all the configured DHCP server(s).
8. The combined S-GW and P-GW sends a DHCP REQUEST to the first DHCP
server(s) sending the DHCP OFFER.
Id:0900d8058089fd45 59
DN0822654 Issue 1-4
with GTP variant

and the Gx event related to IP address allocation is enabled in the Gx session, the
combined S-GW and P-GW sends another Credit Control Request message over
the Gx interface to the PCRF, informs the PCRF about the allocated IP address.
11. The PCRF responds to the Credit Control Request message with the Credit Control
Answer message.
12. If RADIUS accounting is enabled, the combined S-GW and P-GW sends Accounting
Request message START to the RADIUS server.
13. The RADIUS server responds to Accounting Request with Accounting Response
message.
14. The combined S-GW and P-GW responds to Create Session Request message with
a Create Session Response message. If the RADIUS accounting is configured as
optional, the combined S-GW and P-GW does not wait for Accounting Response
message.

bearer is deleted from the combined S-GW and P-GW. In this procedure, only the
played.
Figure 48 Session deletion initiated from access network in combined S-GW and P-
GW
1. The MME or the SGSN sends a Delete Session Request message to the combined
S-GW and P-GW.
2. If the Gx session is active, the combined S-GW and P-GW sends a Credit Control
60 Id:0900d8058089fd45
DN0822654 Issue 1-4
with GTP variant
Answer message.
4. If RADIUS accounting is enabled, the combined S-GW and P-GW sends Accounting
Request message STOP to the RADIUS server.
5. The combined S-GW and P-GW responds to the Delete Session Request message
with a Delete Session Response message. Note that the combined S-GW and PGW
does not wait for Accounting Response message.
7. If DHCPv4 address allocation is in use, the combined S-GW and P-GW sends the
DHCP RELEASE message to the DHCPv4 server.
10.4 Session deletion initiated from combined S-GW and P-GW

The following figure illustrates the signaling related to the procedure in which the
combined S-GW and P-GW deletes the default bearer. In this procedure, only the
played.
Figure 49 Session deletion initiated from combined S-GW and P-GW

The session deletion procedure initiated from combined S-GW and P-GW is as follows:
1. If the Gx session is active, the combined S-GW and P-GW sends a Credit Control
Answer message.
3. If RADIUS accounting is enabled, the combined S-GW and P-GW sends an
Accounting Request message STOP to the RADIUS server.
4. The combined S-GW and P-GW sends a Delete Bearer Request message to the
MME or the SGSN. Note that the combined S-GW and P-GW does not wait for an
Accounting Response message from the RADIUS server.
Id:0900d8058089fd45 61
DN0822654 Issue 1-4
with GTP variant
5. The MME or the SGSN responds to the Delete Bearer Request message with a
Delete Bearer Response message.
7. If DHCPv4 address allocation is in use, the combined S-GW and P-GW sends the
DHCP RELEASE message to the DHCPv4 server.

bearer is modified to the combined S-GW and P-GW.
Figure 50 Session modification initiated from access network

The session modification procedure initiated from access network is as follows:
1. The MME or the SGSN sends a Modify Bearer Request message to the combined
S-GW and P-GW.
2. If the Gx session is active, and if the session modification matches with any of the
enabled Gx trigger events, the combined S-GW and P-GW sends a Credit Control
Answer message.
4. The combined S-GW and P-GW responds to the Modify Bearer Request message
with a Modify Bearer Response message.
message.
62 Id:0900d8058089fd45
DN0822654 Issue 1-4
with GTP variant
Modify Bearer Command message
1. The MME or the SGSN sends a Modify Bearer Command message to the combined
S-GW and P-GW.
2.a In an error case the combined S-GW and P-GW responds to the Modify Bearer
Command message with a Modify Bearer Failure Indication message.
2.b In a successful case the combined S-GW and P-GW responds to the Modify Bearer
Command message with an Update Bearer Request message.
3.b The MME or the SGSN responds to the Update Bearer Request message with an
Update Bearer Response message.
10.6 Paging
For more information on paging in combined S-GW and P-GW with GTP variant, see
Session management in S-GW with PMIP variant.
Id:0900d8058089fd45 63
DN0822654 Issue 1-4
with Gn interface

P-GW with Gn interface
11.1 Overview
Session management is a basic combined S-GW and P-GW functionality that allows
creating, maintaining, and deleting end-user sessions called PDP contexts. Flexi NG as
a combined S-GW and P-GW supports the following session management procedures:
• UE-initiated PDP context activation, modification, and deactivation.
• Network-initiated PDP context modification and deactivation.
The QoS change, for example, bit rate (APN-AMBR/MBR) modification of a bearer, for
radio access change among E-UTRAN, UTRAN, and GERAN supports the following:
• When Flexi NG is moved from Gn-based GERAN/UTRAN to E-UTRAN/S4-based
UTRAN, it supports the following session management procedures:
• Create Session Request
• Create Session Response
• Modify Bearer Request
• Modify Bearer Response
• When Flexi NG is moved from S4-based UTRAN or E-UTRAN, it supports the fol-
lowing session management procedures:
• Update PDP Context Request
• Update PDP Context Response
• Flexi NG does not support Modify Bearer Command procedure.
Flexi NG supports up to 11 primary PDP contexts for each end user, while secondary
PDP contexts are not currently supported.
Note: This chapter describes the session creation, deletion, and modification proce-
dures related to Gn interface.
11.2 Interfaces of combined S-GW and P-GW

The following figure shows the logical interfaces of combined S-GW and P-GW related
to the session management.
Figure 52 Interfaces of combined S-GW and P-GW

context is created to the combined S-GW and P-GW. In this procedure, only messages
that are sent to or received by the combined S-GW and P-GW are displayed.
64 Id:0900d80580857306
DN0822654 Issue 1-4
with Gn interface
Figure 53 Session creation in combined S-GW and P-GW

The session creation procedure in combined S-GW and P-GW is as follows:
1. The SGSN sends a Create PDP Context Request message to the combined S-GW
and P-GW.
2. The combined S-GW and P-GW responds to the Create PDP Context Request
message with a Create PDP Context Response message. Note that if the RADIUS
accounting is configured as optional, the combined S-GW and P-GW does not wait
for the Accounting Response message.

context is deleted from the combined S-GW and P-GW. In this procedure, only
played.
Figure 54 Session deletion initiated from access network (combined S-GW and P-
GW)
Id:0900d80580857306 65
DN0822654 Issue 1-4
with Gn interface
2. The combined S-GW and P-GW responds to the Delete PDP Context Request
message with a Delete PDP Context Response message. This step can be started
before the RADIUS server responds.
11.5 Session deletion initiated from combined S-GW and P-GW

The following figure illustrates the signaling related to procedure, in which the combined
S-GW and P-GW deletes the primary PDP context. This can happen for example due to
expiration of PDP context inactivity timer. In this procedure, only messages that are
either sent to or received by the combined S-GW and P-GW are displayed.
Figure 55 Session deletion initiated from combined S-GW and P-GW

The session deletion procedure initiated from combined S-GW and P-GW is as follows:
1. The combined S-GW and P-GW sends a Delete PDP Context Request message to
the SGSN.
11.6 Session handover from Gn interface to S11 interface

The following figure illustrates the signalling related to procedure, in which there is
session handover from Gn interface to S11 interface. In this procedure, only messages
that are either sent to or received by SGSN, combined S-GW and P-GW, and MME are
displayed.
66 Id:0900d80580857306
DN0822654 Issue 1-4
with Gn interface
Figure 56 Session handover from Gn interface to S11 interface

The session handover procedure from Gn interface to S11 interface is as follows:
1. The SGSN sends a Create PDP Context Request to combined S-GW and P-GW.
2. The combined S-GW and P-GW responds to the Create PDP Context Request with
a Create PDP Context Response.
3. The MME sends a Create Session Request to combined S-GW and P-GW.
4. The combined S-GW and P-GW responds to the Create Session Request with a
Create Session Response.
5. The MME sends a Modify Bearer Request to combined S-GW and P-GW.
6. The combined S-GW and P-GW responds to the Modify Bearer Request with a
Modify Bearer Response.
11.7 Session handover from S11 interface to Gn interface

session handover from S11 interface to Gn interface. In this procedure, only messages
that are either sent to or received by SGSN, combined S-GW and P-GW, MME, and
PCRF are displayed.
Id:0900d80580857306 67
DN0822654 Issue 1-4
with Gn interface
Figure 57 Session handover from S11 interface to Gn interface

The session handover procedure from S11 interface to Gn interface is as follows:
1. The MME sends a Create Session Request to combined S-GW and P-GW.
2. The combined S-GW and P-GW responds to the Create Session Request with a
CCR.
3. The PCRF sends a CCA to the combined S-GW and P-GW.
4. The combined S-GW and P-GW responds to the CCA with a Create Session
Response.
5. The MME sends a Modify Bearer Request to combined S-GW and P-GW.
6. The combined S-GW and P-GW responds to the Modify Bearer Request with a
CCR.
7. The PCRF sends a CCA to the combined S-GW and P-GW.
8. The combined S-GW and P-GW responds to the CCA with a Modify Bearer
Response.
68 Id:0900d80580857306
DN0822654 Issue 1-4
with Gn interface
9. The SGSN sends Updated PDP Context Request to combined S-GW and P-GW.
10. The combined S-GW and P-GW sends CCR to PCRF.
11. The PCRF responds to the CCR with CCA.
12. The combined S-GW and P-GW responds to the Updated PDP Context Request
with a Updated PDP Context Response.
13. The PCRF sends a RAR to combined S-GW and P-GW.
14. The combined S-GW and P-GW sends a Update PDP Request to SGSN.
15. The SGSN responds to the Update PDP Context Request with a Update PDP
Context Response.
16. The combined S-GW and P-GW sends RAA to PCRF.
17. The SGSN sends Delete PDP Context Request to combined S-GW and P-GW.
18. The combined S-GW and P-GW sends CCR to PCRF.
19. The PCRF responds to CCR with CCA.
20. The combined S-GW and P-GW responds to Delete PDP Context Request with a
Delete PDP Context Response.
11.8 Session handover from S5 interface to Gn interface

session handover from S5 interface to Gn interface. In this procedure, only messages
that are either sent to or received by SGSN, P-GW, S-GW, and PCRF are displayed.
Id:0900d80580857306 69
DN0822654 Issue 1-4
with Gn interface
Figure 58 Session handover from S5 interface to Gn interface

The session handover procedure from S5 interface to Gn interface is as follows:
1. The S-GW sends a Create Session Request to P-GW.
2. The P-GW sends CCR to PCRF.
3. The PCRF responds to CCR with CCA.
4. The P-GW responds to the Create Session Request with a Create Session
Response.
5. The SGSN sends a Update PDP Request to the P-GW with RAT type change.
6. The P-GW sends CCR to the PCRF with event trigger RAT type set to UTRAN.
7. The PCRF responds to the CCR with a CCA.
8. The PCRF sends RAR with QoS modification to P-GW.
9. The P-GW sends Update PDP Context Request to the SGSN.
10. The SGSN responds to the Update PDP Context Request with a Update PDP
Context Response.
11. The P-GW responds to the RAR with a RAA.
12. The SGSN sends Delete PDP Context Request to the P-GW.
13. The P-GW sends CCR to the PCRF.
14. The PCRF responds to the CCR with a CCA.
15. The P-GW responds to the Delete PDP context Request with a Delete PDP Context
Response.
70 Id:0900d80580857306
DN0822654 Issue 1-4
with Gn interface
11.9 Session handover from Gn interface to S5 interface

session handover from Gn interface to S5 interface. In this procedure, only messages
that are either sent to or received by SGSN, P-GW, and PCRF are displayed.
Figure 59 Session handover from Gn interface to S5 interface

The session handover procedure from Gn interface to S5 interface is as follows:
1. The SGSN sends a Create PDP Context Request to P-GW.
3. The PCRF responds to CCR with a CCA.
4. The P-GW responds to Create PDP Context Request with a Create PDP Context
Response.
5. The S-GW sends a Modify Bearer Request to P-GW with RAT type change.
7. The PCRF responds to CCR with a CCA.
8. The P-GW responds to Modify Bearer Request with a Modify Bearer Response.
9. The PCRF sends RAR with QoS modification to P-GW.
10. The P-GW sends Modify Bearer Request to the S-GW.
11. The S-GW responds to the Modify Bearer Request with a Modify Bearer Response.
12. The P-GW responds to RAR with a RAA.
Id:0900d80580857306 71
DN0822654 Issue 1-4
with Gn interface
13. The S-GW sends Delete Bearer Request to P-GW.

15. The PCRF responds to the CCR with CCA.
16. The P-GW responds to the Delete Bearer Request with a Deleter Bearer Response.
72 Id:0900d80580857306
DN0822654 Issue 1-4
Session Management Reference Guide Path management
12 Path management
This chapter describes Flexi NG restart procedures, Echo messaging and Path failure.
12.1 Overview
This chapter describes Flexi NG restart procedures, Echo messaging, and Path failure.
Across GTP-C and GTP-U based interfaces, a MME, eNodeB, SGSN, S-GW and P-GW
utilize Echo Request and Echo Response messages for detecting remote peer failure.
The following figure illustrates the signaling related to path management. S-GW will
send Echo Requests to MME, SGSN or eNodeB and P-GW, if those nodes have
sessions of the S-GW. P-GW will send Echo Requests to S-GW, if S-GW has sessions
of P-GW. Echo Requests are exchanged between S-GW and P-GW only there is GTP-
based S5 interface between S-GW and P-GW. Echo Requests are not sent in the PMIP-
based S5 interface.
Id:0900d805807ba997 73
DN0822654 Issue 1-4
Path management Session Management Reference Guide
Figure 60 Path management

If path failure is detected, Flexi NG logs the event, raises the alarm 71503 (connection
lost to peer network element), and initiates the path failure procedure that deactivates
all sessions related to the path. The deactivation is done in slowloop and possible
Accounting, Gx, and charging sessions are terminated.
For more information on alarms, see Flexi NG Alarms.
74 Id:0900d805807ba997
DN0822654 Issue 1-4
Session Management Reference Guide Path management
12.2 GTP-C based restart procedures

Across GTP-C based interfaces, a SGSN/MME and a NG utilize Echo Request and
Echo Response messages or GTP-C messages containing the Recovery IE to detect
and handle a restart.
A GTP-C entity maintains two Restart counters:
• In volatile memory a remote Restart counter of a peer with which the entity is in
contact.
• In non-volatile memory own, or local Restart counter that was sent to a peer.
After a GTP-C entity restarts, it immediately increments all local Restart counters and
clears all remote Restart counters.
A GTP-C entity has either a common local Restart counter for all peers, or it has a
separate local Restart counter for each peer.
A GTP-C entity is prepared to receive an Echo Request message at any time and it
replies with an Echo Response message. The Restart counter is included in an Echo
Response message.
The GTP-C entity that receives an Echo Response or a Recovery Information Element
in a GTP-C message from a peer compares the received remote Restart counter value
with the previous Restart counter value stored for that peer entity.
• If no previous value was stored the Restart counter value received in the Echo
Response or in the GTP-C message shall be stored for the peer.
• If the value of a Restart counter previously stored for a peer is smaller than the
Restart counter value received in the Echo Response message or the GTP-C
message, this indicates that the entity that sent the Echo Response or the GTP-C
message has restarted. The received, new Restart counter value shall be stored by
the receiving entity, replacing the value previously stored for the peer.
• If the value of a Restart counter previously stored for a peer is larger than the Restart
counter value received in the Echo Response message or the GTP-C message, this
indicates a possible race condition (newer message arriving before the older one).
The received new Restart counter value shall be discarded and an error may be
logged.
12.3 Echo Request and Echo Response

The Echo messaging functionality is used to verify that a connection to a network
element works. Flexi NG and SGSNs/MMEs can exchange Echo Requests and Echo
Responses (in GTP-C or GTP-U) at configurable intervals to check that the path
between them is alive.
Flexi NG supports both SGSN/MME-initiated and Flexi NG-initiated Echo Requests and
Echo Responses for GTP-C and GTP-U protocols.
12.3.1 Information elements in an Echo Response message

Echo Response contains the mandatory Recovery information element that indicates if
a SGSN/MME or Flexi NG has restarted. The Recovery information element contains
the local Restart Counter value for the sending network element.
Id:0900d805807ba997 75
DN0822654 Issue 1-4
Path management Session Management Reference Guide
When Flexi NG receives an Echo Response message, it compares the received Restart
Counter value with the previous stored Restart Counter value. If no previous value was
stored, the received new Restart Counter value is stored.
If the Restart Counter value received in the Echo Response message differs from the
previous stored value, Flexi NG considers the sender of the Echo Response restarted.
In this case, Flexi NG stores the received new Restart Counter value and considers all
PDP contexts/EPS bearer using the peer as inactive. The PDP contexts/EPS bearer
that use the peer are deactivated without notifying the peer element. The deactivation is
done in slowloop and possible Accounting, Gx and charging sessions are terminated.
The Restart Counter value is only used in the GTP-C path. In GTP-U, Flexi NG sets the
Restart Counter value to zero.
12.3.2 Echo Request and Echo Response configuration parameters

Echo messaging configuration involves setting the interval between Echo Requests sent
on paths from Flexi NG to SGSNs/MMEs, the length of the time Flexi NG waits for an
Echo Response from a SGSN/MMEs before resending an Echo Request, and the
number of times Echo Requests are sent before the path is considered to be down and
the path failure procedure is initiated.
The Echo Response waiting time is configured with the T3-RESPONSE timer. The
number of times an Echo Request is sent is configured with the N3-REQUESTS
counter.
GTP-U and GTP-C use separate Echo messaging configurations. For a full list of the
parameters and value ranges, see Flexi NG CLI Reference Guide.
12.3.3 Recovery information element in other PDP contexts/EPS Bearers

The SGSN/MME includes a Recovery IE into PDP context/EPS bearer if the
SGSN/MME is in contact with Flexi NG for the very first time or if the SGSN/MME has
restarted recently and the new Restart Counter value has not yet been indicated to the
NG. Flexi NG handles a Recovery IE in the PDP context/EPS bearer message element
in the same way as when receiving an Echo Response message.
76 Id:0900d805807ba997
DN0822654 Issue 1-4
Session Management Reference Guide Indirect data forwarding
13 Indirect data forwarding

Indirect data forwarding is an optional feature that can be used to achieve lossless
handover in a E-UTRAN network without X2 connectivity between eNodeBs, or in
combined E-UTRAN and UTRAN networks when changing between E-UTRAN and
UTRAN radio accesses.
When Indirect data forwarding is in use, a source eNodeB can forward downlink packets
indirectly to a new target eNodeB through an S-GW after the UE connection is switched
to the target eNodeB.Indirect data forwarding can be used in handover procedures with
or without S-GW relocation. The following figure illustrates the data path during a
handover procedure with S-GW relocation:
Figure 61 Data path during a handover procedure with S-GW relocation

1: A P-GW sends downlink packets to a source S-GW until the target S-GW informs that
the user has been moved under a new S-GW.
2: The source S-GW uses an existing GTP-U tunnel and forwards the packet to an
eNodeB.
3, 4, 5, 6: If the source eNodeB has already lost connectivity with the UE, Indirect For-
warding Tunnels are used to forward the packet to its final destination.
The MME/SGSN determines if indirect data forwarding is needed in the handover pro-
cedure. The MME/SGSN selects the S-GW that is used for forwarding. The Indirect Data
Forwarding Tunnel is an independent forwarding tunnel that doesn't have any relation
with the actual PDN connection. This means that an Indirect Data Forwarding Tunnel
can be also created to an S-GW that doesn't handle an end user's PDN connections.
If an Indirect Data Forwarding Tunnel is created to an S-GW with end-user PDN con-
nections, the MME/SGSN is already aware of the allocated S-GW control plane TEID
for the S11/S4 interface. That same TEID is used as an identifier when creating a for-
warding tunnel. Otherwise, IMSI is used as the identifier, and S11/S4 control plane
Id:0900d805807f6be2 77
DN0822654 Issue 1-4
Indirect data forwarding Session Management Reference Guide
TEIDs are exchanged during Indirect Data Forwarding Tunnel creation. The S-GW allo-
cates one user plane forwarding endpoint for the Indirect Data Forwarding Tunnel.
The same endpoint is provided for all interface types (different F-TEID for S1-U, S4,
S12). An MME/SGSN can choose the F-TEID to be delivered to a peer network element
based on the handover procedure type. The S-GW reserves an entry for the Indirect
Data Forwarding Tunnel from the bearer database. This means that the forwarding
tunnel uses the same licensed resource as default or dedicated bearers related to PDN
connections.
The maximum time an Indirect Data Forwarding Tunnel resource can exist without being
released by the peer element that created the resource is 30 seconds. If the peer
element has not released the Indirect Data Forwarding Tunnel resource within 30
seconds, a timer deactivates the resource.
From the 2N high availability point of view, system redundancy and bearer continuity are
not relevant for Indirect data forwarding bearers due to the nature of the handover pro-
cedure. As indirect data forwarding only takes a few seconds, the handover procedure
is completed before the new active blade is capable of continuing data forwarding after
a switchover.
The following messages are used between an MME/SGSN and S-GW when creating
and deleting indirect data forwarding tunnels:
Figure 62 Indirect data forwarding message flow

1. An MME/SGSN sends a Create Indirect Data Forwarding Tunnel Request to an S-
GW.
2. The S-GW responds with a Create Indirect Data Forwarding Tunnel Response. The
forwarding tunnel is established, and data is forwarded.
3. The MME/SGSN sends a Delete Indirect Data Forwarding Tunnel Request to an S-
GW.
4. The S-GW responds with a Delete Indirect Data Forwarding Tunnel Response. The
forwarding tunnel is removed.
For more information on the messaging related to indirect data forwarding, see Message
Flow in S11 Interface Description and Message Flow in S4 Interface Description.
78 Id:0900d805807f6be2
DN0822654 Issue 1-4
Session Management Reference Guide Idle state signaling reduction (ISR)
14 Idle state signaling reduction (ISR)
Idle state signaling reduction (ISR) is used to reduce location updates (RAUs, TAUs)
while the UE is in idle state and changes between E-UTRAN and UTRAN access. This
allows the operator to save radio resources, especially if the UE is in the radio access
border area with frequently changing between the E-UTRAN and UTRAN cells, and also
extends battery life in many UE models. ISR complements the selective routing area
update already used in GERAN and UTRAN in pre-release 8 SGSNs.
An MME or an S4-based SGSN activates the ISR towards the UE and S-GW. The ISR
activation is also indicated between an MME and an SGSN, and the UE is kept regis-
tered in both. Then, when the S-GW receives downlink data for the UE, it triggers paging
for the UE towards both the MME and the SGSN. The UE responds in the access it is
currently located in, and the bearer resources are reserved and data is forwarded to it.
If the UE wishes to send data towards the network, it requests for the bearer resources
in the access it is located in and the bearer resources are reserved in the normal
manner. When the UE moves to active state, the MME/SGSN typically deactivates the
ISR and activates it again when the UE moves to idle state.
14.1 ISR activation

Flexi NG uses the following messaging in ISR activation:
Figure 63 ISR activation

1. A session is established (Create Session Response - Request)
2. Once a session is established, the SGSN sends a Modify Bearer Request to S-GW
with the ISRAI flag set to 1 to activate ISR.
3. S-GW responds to the SGSN with a Modify Bearer Response.
14.2 ISR deactivation with a Delete Session Request without

PDN connection release and peer CN node notification
Flexi NG uses the following messaging when deactivating ISR with the Delete Session
Request without releasing PDN connections and notifying the peer core network (CN)
node:
Id:0900d805808386eb 79
DN0822654 Issue 1-4
Idle state signaling reduction (ISR) Session Management Reference Guide
Figure 64 ISR deactivation with a Delete Session Request without PDN connection
release and peer CN node notification
1. MME sends a Delete Session Request to S-GW with the Originating Node information
element present and the Cause set to any other value than ISR deactivation. This
removes the originating endpoint reference and deactivates ISR locally in the S-GW
without deleting local resources.
2. The S-GW responds to the MME with a Delete Session Response.
3. In a multiple default bearer case, the consequent Delete Session Requests and
Delete Session Responses between MME and S-GW only acknowledge the requests:
ISR deactivation was completed with steps 1 and 2.
14.3 ISR deactivation with a Delete Session Request with PDN

connection release and peer CN node notification
Flexi NG uses the following messaging when deactivating ISR with a Delete Session
Request when PDN connections are released and the peer CN node is notifiied:
80 Id:0900d805808386eb
DN0822654 Issue 1-4
Figure 65 ISR deactivation with a Delete Session Request with PDN connection
release and peer CN notification
1. The MME sends a Delete Session Request to the S-GW without the Originating Node
information element, the Cause set to ISR deactivation, and the OI flag set to 1. This
deactivates ISR and starts the deletion of local sessions. Note that the messaging in an
HSS-initiated detach differs from this: see section HSS-initiated detach.
2. The S-GW sends a Delete Session Request to P-GW, and the P-GW responds with
a Delete Session Response.
3. The S-GW sends the SGSN a Delete Bearer Request with the Cause set to ISR deac-
tivation. This message removes all subscriber ISR information at the same time (instead
of using separate messages for ISR deactivation). The SGSN responds with a Delete
Bearer Response.
4. The S-GW responds to MME with a Delete Session Response.
5. In a multiple default bearer case, the consequent requests (MME-SGW Delete
Session Request - Delete Session Response and S-GW - P-GW Delete Session
Request - Delete Session Response) are carried out without notifiying the peer CN node
(SGSN-S-GW messaging described in step 3), as ISR is already deactivated. Local
session deletion is carried out if the OI flag is set to 1 in the messaging between S-GW
and P-GW.
14.4 ISR deactivation with a Modify Bearer Request

Flexi NG uses the following messaging when deactivating ISR with the Modify Bearer
Request message:
Id:0900d805808386eb 81
DN0822654 Issue 1-4
Idle state signaling reduction (ISR) Session Management Reference Guide
Figure 66 ISR deactivation with Modify Bearer Request

1. SGSN sends a Modify Bearer Request to S-GW with ISRAI set to 0, deactivating ISR
and removing the originating endpoint reference.
2. The S-GW sends a Delete Bearer Request to MME, and the MME responds with a
Delete Bearer Response.
3. The S-GW sends a Modify Bearer Response to the SGSN.
4. In a multiple default bearer case, the consequent messaging (Modify Bearer Request
- Reponse) is carried out between SGSN and S-GW.
14.5 ISR deactivation triggered by a Create Session Request

Flexi NG’s ISR implementation prevents creating a new session for a subscriber if ISR
is active. This means that the S-GW locally deactivates ISR if a Create Session Request
is received while ISR is active.
Figure 67 ISR deactivation with a Create Session Request

1. SGSN sends a Create Session Request to S-GW to create a new session. This
causes ISR deactivation.
2. The S-GW sends a Proxy Binding Update to P-GW, and the P-GW responds with a
Proxy Binding Acknowledgement.
3. The S-GW sends a Delete Bearer Request to MME, and the MME responds with a
Delete Bearer Request.
82 Id:0900d805808386eb
DN0822654 Issue 1-4
4. The S-GW sends a Create Session Response to the SGSN.
14.6 HSS-initiated detach

The HSS-intiated detach messaging in Flexi NG follows 3GPP TS 23.401 in all other
cases apart from the following execption:
Figure 68 HSS-initiated detach

1-3: The assumed starting situation is that HSS sends simultaneous detach messages
to MME and SGSN. When the MME receives the detach, it sends the first (initial) EBI 5
Delete Session Request to S-GW, deactivating ISR. S-GW responds to the MME with a
Delete Session Response.
4. SGSN sends the second EBI 5 Delete Session Request to S-GW, and S-GW starts
session deletion in the P-GW.
5. As the MME started the messaging , the first EBI 6 Delete Session Request sent by
the SGSN to the S-GW (instead of the reception of both Delete Session Requests from
both endpoints as suggested by 3GPP TS 23.401) triggers the default bearer deletion.
6. When the MME sends an EBI 6 Delete Session Request, the S-GW responds with a
Delete Session Response with the Cause set to Context not Found, as the session was
already deleted by the S-GW (step 5).
Id:0900d805808386eb 83
DN0822654 Issue 1-4
Multiple PDN connections Session Management Reference Guide
15 Multiple PDN connections

Flexi NG supports upto 11 PDN connections for each subscriber.
15.1 Access point usage

LTE
In LTE, multiple PDN connections are supported with both S5(GTP) and S5 (PMIP) vari-
ants.
With S5 GTP, multiple default bearers can be created either to different or to the same
access point.
With S5 PMIP, multiple default bearers can be created only to different access points as
specified in 3GPP specification 3GPP TS 29.275. In case multiple default bearers are
created to the same access point, then Flexi NG first deactivates the existing default
bearer and then continues the creation of new multiple default bearers.
GGSN
Multiple primary PDP contexts can be created either to different or to the same access
point.
15.2 Aggregate maximum bit rate

Flexi NG supports aggregate maximum bit rate (APN-AMBR) per PDN connection in this
release.
84 Id:0900d805807fdd71
DN0822654 Issue 1-4
Session Management Reference Guide Collision handling in session management
16 Collision handling in session management
16.1 Overview
Flexi NG can handle simultaneous procedures for the same PDN connection without
confusing the PDN connection related data. The collision handling functionality in
Session Management determines the precedence of the procedure based on the
behavior defined in specifications and acts accordingly.
The procedures with similar precedence are queued and executed in received order.
The preferred procedure can cancel the ongoing procedure and continue. Vice versa the
preferred procedure can discard incoming procedures.
Figure 69 Collision handling in session management

The following figure illustrates collision handling in Session Management. The example
does not name the procedures but describes collision handling scenarios in general
level.
1. Element 1 initiates procedure (a) for PDN connection.
2. Element 2 initiates procedure (b) with same precedence than ongoing procedure for
same PDN connection. Procedure (b) will be queued and executed after procedure
(a) is finished.
3. Element 1 initiates procedure (c) with same precedence than ongoing procedure for
same PDN connection. Procedure (c) will be queued and executed after procedure
(b) is finished.
4. Element 2 initiates preferred procedure (d) compared with procedure (c), which
means procedure (c) is cancelled and procedure (d) is started immediately.
5. Element 1 initiates procedure (e) while preferred procedure (d) is ongoing, which
means procedure (e) is discarded.
Id:0900d805807bb48b 85
DN0822654 Issue 1-4
Collision handling in session management Session Management Reference Guide
16.2 Collision during PDP context procedures
16.2.1 PDP context activation procedure collisions

The table below describes the actions on different types of collisions during a PDP
context activation procedure.
Incoming PDP context request Ongoing Create PDP

Colliding Create PDP context • The new request is ignored
request (same APNs) • The ongoing Create PDP context
request is continued
Colliding Create PDP context • The ongoing Create PDP context
request(different APNs) request activation procedure is
silently cancelled
• The new Create PDP context
Colliding Delete PDP context • The ongoing Create PDP context
request request activation procedure is
silently cancelled
• The new Delete PDP context
Colliding network initiated Delete • The ongoing Create PDP context
PDP context request request is cancelled
Table 2 PDP context activation procedure collisions
16.2.2 PDP context deactivation procedure collisions

The below table describes the actions on different types of collisions during a PDP
context deactivation procedure.
Incoming PDP context request Ongoing delete PDP context

Colliding Create PDP context • Ongoing deletion procedure is
request during ongoing PDP continued
context deactivation • Incoming PDP context activation
request is dropped
Colliding Delete PDP context • Ongoing deletion procedure is
request during ongoing PDP continued
context deactivation • Incoming PDP context deactiva-
tion request is dropped
Colliding Delete PDP context • Ongoing deletion procedure is
response during ongoing PDP continued
context deactivation • Incoming PDP context deactiva-
tion response is dropped
Table 3 PDP context deactivation procedure collisions
86 Id:0900d805807bb48b
DN0822654 Issue 1-4
Session Management Reference Guide Collision handling in session management
16.2.3 Network initiated PDP context deactivation procedure collisions

The below table describes the actions on different types of collisions during a network
initiated PDP context deactivation procedure.
Incoming PDP context request Ongoing network initiated delete

PDP context
Colliding Create PDP context • Ongoing network initiated
request during ongoing network deletion procedure is continued
initiated PDP context deactivation • Incoming PDP context activation
request is rejected by sending a
PDP context create response to
peer with proper cause code
Colliding Delete PDP context • Ongoing network initiated
request during ongoing network deletion procedure is continued
initiated PDP context deactivation • Incoming PDP context deactiva-
tion request is dropped
Colliding Delete PDP context • Ongoing network initiated
response during ongoing network deletion procedure is continued
initiated PDP context deactivation • Incoming PDP context deactiva-
tion response is dropped
Table 4 Network initiated PDP context deactivation procedure collisions
16.2.4 Update PDP context request collisions

The below table describes the actions on different types of collisions resulting from an
Update PDP Context Request.
Incoming PDP context request Effect on Update PDP Context

Colliding Update PDP Context Update PDP Context Request is
Request during an ongoing, rejected using Cause IE value Non-
incomplete Create PDP Context existent.
procedure
Request during an ongoing, rejected using Cause IE value Non-
incomplete SGSN-initiated Delete existent.
PDP Context procedure
Request during an ongoing, silently ignored.
incomplete Flexi NG initiated
Delete PDP Context procedure
Table 5 Update PDP context request collisions
Id:0900d805807bb48b 87
DN0822654 Issue 1-4
Collision handling in session management Session Management Reference Guide
Incoming PDP context request Effect on Update PDP Context

Colliding Update PDP Context The previous Update PDP Context
Request during an ongoing, procedure is cancelled silently. A
incomplete Update PDP Context new Update PDP Context procedure
procedure based on the new Update PDP
Context Request is started.
Colliding Create PDP Context The incoming Create PDP Context
Request during an ongoing, Request is dropped, and the Update
incomplete Update PDP Context PDP Context procedure is contin-
procedure ued.
Colliding network initiated Delete Update PDP Context procedure is
PDP Context Request during an cancelled, and the Delete PDP
ongoing, incomplete Update PDP Context procedure is started.
Context procedure
Colliding Flexi NG initiated Delete Update PDP Context procedure is
PDP Context Request during an cancelled, and the Delete PDP
ongoing, incomplete Update PDP Context procedure is started.
Context process
Table 5 Update PDP context request collisions (Cont.)
The log level used in Update PDP Context Request collision log printouts is debug.
88 Id:0900d805807bb48b
DN0822654 Issue 1-4
Session Management Reference Guide Glossary
17 Glossary
Term Definition
3GPP 3rd Generation Partnership Project
AAA Authentication, Authorization and Accounting
CDR Charging Data Record
DNS Domain Name System
DSCP DiffServ Code Point
eNodeB Evolved Node B
GGSN Gateway GPRS Support Node
Gi Gi interface
Gn Gn interface
Gp Gp interface
GPRS General Packet Radio Service
GTP GPRS Tunnelling Protocol
IE Information Element
IMSI International Mobile Subscriber Identity
IP Internet Protocol
LTE Long Term Evolution
NG Network Gateway
OCS Online Charging System
PDP Packet Data Protocol
P-GW Packet Data Network Gateway
QoS Quality of Service
RADIUS Remote Authentication Dial-In User Service
SAE System Architecture Evolution
SCLI Structured Command Line Interface
SGSN Serving GPRS Support Node
S-GW Serving Gateway
TEID Tunnel Endpoint Identifier
UE User Equipment
Table 6 Session management glossary
Id:0900d80580777f38 89
DN0822654 Issue 1-4

Flexi Network Gateway Rel. 10 CD8, Operating Documentation, v. 1

Uploaded by

Copyright:

Available Formats

You might also like

Flexi Network Gateway Rel. 10 CD8, Operating Documentation, v. 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Flexi Network Gateway Rel. 10 CD8, Operating Documentation, v. 1

Uploaded by

Copyright:

Available Formats

Flexi Network Gateway Rel.

Session Management Reference Guide

f Important Notice on Product Safety

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit

1 Changes in Flexi NG Session Management Reference Guide . . . . . . . . 9

2 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Session management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Session management in GGSN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Session management in S-GW with PMIP variant. . . . . . . . . . . . . . . . . 28

6 Session management in S-GW with GTP variant . . . ...... ........ 36

6.6 Session modification initiated from P-GW. . . . . . . . . . . . . . . . . . . . . . . . 40

7 Session management in P-GW with PMIP variant . . . . . . . . . . . . . . . . . 44

8 Session management in P-GW with GTP variant . . . . . . . . . . . . . . . . . . 50

9 Session management in combined S-GW and P-GW with PMIP variant 57

10 Session management in combined S-GW and P-GW with GTP variant. 58

11 Session management in combined S-GW and P-GW with Gn interface 64

13 Indirect data forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

14 Idle state signaling reduction (ISR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

15 Multiple PDN connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

16 Collision handling in session management . . . . . . . . . . . . . . . . . . . . . . 85

Figure 44 Session modification initiated from PCRF, GTP-variant P-GW . . . . . . . 55

1 Changes in Flexi NG Session Management

1.1 Changes between release 10 CD5.2 and release 10CD8

1.2 Changes between release 10 CD4 and release 10 CD5.2

1.3 Changes between release 10 CD2 and release 10 CD4

1.4 Changes in release 10 CD2

Changes between User Guide 1-1 and Session Management 1-0

2 About this document

3 Session management overview

3.1 Session profiles

Figure 1 Properties related to sessions

3.2 S-GW profiles in session management

Figure 2 Profiles linked to S-GW

. For instructions, see Configuring S-GW profiles in Flexi NG User Guide.

3.3 Session profiles in session management

Figure 3 Session profile role in session creation

Configuration profile Description

Table 1 Separate configuration profiles

4 Session management in GGSN

4.2 Primary PDP context messaging

4.2.1 GGSN interfaces

Figure 4 Interfaces of GGSN

4.2.2 Session creation

Figure 5 Session creation in GGSN (primary PDP context)

4.2.3 Session deletion initiated from access network

Figure 6 Session deletion initiated from access network

4.2.4 Session deletion initiated from GGSN

Figure 7 Session deletion initiated from GGSN

5. If the RADIUS accounting is enabled, the GGSN sends an Accounting Request

4.2.5 Session update initiated from access network

Figure 8 Session update initiated from access network

4.2.6 Session update initiated from PCRF

Figure 9 Session update initiated from PCRF

4.3 Secondary PDP context messaging

4.3.1 Session creation

Figure 10 Session creation in GGSN (secondary PDP context)

4.3.2 Session deletion initiated from access network