<<

. 32
( 132 .)



>>

RESPONSE)
- restart counter: 73 (49h)
- Header Length: 61 (3dh)
Selection mode
- Tunnel endpoint id: 85 (00000055h)
- MS or network provided APN, subscribed
- Sequence number: 49 (31h)
Tunnel Endpoint Iden Data I
- No extension header
- Tunnel endpoint id: 84 (00000054h)
Cause
Tunnel Endpoint Iden CP
- acceptance: request accepted
- id: 85 (00000055h)
Reordering Required :no
NSAPI
Recovery
- NSAPI: 5(5h)
- restart counter: 27 (1bh)
End User Address
Tunnel Endpoint Iden Data I
- length : 6 (0006h)
- Tunnel endpoint id: 180 (000000B4h)
- PDP type organisation : IETF
Tunnel Endpoint Iden CP
- PDP type number : 33 (21h)
- id: 179 (000000B3h)
- IPv4 address : 135.2.70.123
Charging ID
Access Point Name
- value : 11829536 (00B48120h)
- length : 24 (0018h)
GGSN Address for Control Plane
- APN : .apn1.mnc001.mcc310.gprs
- length: 4 (4h)
SGSN Address for signalling
- Ipv4 Address: 172.26.131.118
- length: 4 (4h)
GGSN Address for user traffic
- Ipv4 Address: 172.26.143.1
- length: 4 (4h)
SGSN Address for user traffic
- Ipv4 Address: 172.26.131.118
- length: 4 (4h)
Quality of Service Profile
- Ipv4 Address: 172.26.143.1
- length 12 (000Ch)
MSISDN
- allocation/retention priority 3 (03h)
- length : 9 (0009h)
- unacknowledged GTP, LLC, and RLC,
- MSISDN : A1 13 00 01 00 00 00 30 F0
unprotected data
Quality of Service Profile
- delay class 4 (best effort)
- length 12 (000Ch)
- precedence class: low priority
- allocation/retention priority 3 (03h)
- peak throughput : up to 8 000 octet/s
- unacknowledged GTP, LLC, and RLC, unprotected
- mean throughput : best effort
data
- traffic class : background class
- delay class 4 (best effort)
- delivery order: without delivery order
- precedence class: low priority
- delivery of erroneous SDUs: no detect
- peak throughput : up to 8 000 octet/s
- maximum SDU size: 1500
- mean throughput : 100 octet/h
- maximum bit rate for uplink: 64 kbps
- traffic class : background class
- maximum bit rate for downlink: 64 kbps
- delivery order: without delivery order
- residual BER: 1*10-5
- delivery of erroneous SDUs: no detect
- SDU error ratio: 1*10-4
- maximum SDU size: 1500
- transfer delay: 10 ms
- maximum bit rate for uplink: 64 kbps
- traffic handling priority: level 1
- maximum bit rate for downlink: 64 kbps
- guaranteed bit rate for uplink: 64 kbps
- residual BER: 1*10-5
- guaranteed bit rate for downlink: 64 kbps
- SDU error ratio: 1*10-4
Charging Gateway Address
- transfer delay: 10 ms
- length: 4 (04h)
- traffic handling priority: level 1
- Ipv4 Address: 172.26.146.1
- guaranteed bit rate for uplink: 64 kbps
- guaranteed bit rate for downlink:64 kbps



Figure 4.45 Trace PDP context creation. Reproduced by permission of NetHawk Oyj
144 GENERAL PACKET RADIO SERVICE



SGSN
MS BSS GGSN


Dectivate PDP Context Request
1

2
Security Functions
Delete PDP Context Request
3
Delete PDP context Reponse
4
Deactivate PDP Context Accept
5


Figure 4.46 PDP context deactivation


GSN GSN
IP DATAGRAM IP DATAGRAM
Source address : 10.1.2.123 Source address : 10.1.5.34
Destination address : 10.1.5.34 Destination address : 10.1.2.123
DELETE PDP CONTEXT REQUEST DELETE PDP CONTEXT RESPONSE
- Version number: 1 (1h) - Version number: 1 (1h)
- Protocol type: 1 (1h) - Protocol type: 1 (1h)
- Extension header flag: 0 (0h) - Extension header flag: 0 (0h)
- Sequence number flag: 1 (1h) - Sequence number flag: 1 (1h)
- N-PDU number flag: 0 (0h) - N-PDU number flag: 0 (0h)
- Message Type: 20 (DELETE PDP - Message Type: 21 (DELETE PDP
CONTEXT REQUEST) CONTEXT RESPONSE)
- Header Length: 8 (8h) - Header Length: 6 (6h)
- Tunnel endpoint id: 16777296 - Tunnel endpoint id: 16777296
(01000050h) (01000050h)
- Sequence number: 11 (bh) - Sequence number: 11 (bh)
- No extension header - No extension header
Teardown Ind :yesv Cause
NSAPI - acceptance: request accepted
- NSAPI: 5(5h)


Figure 4.47 Trace PDP context deletion. Reproduced by permission Oyj


device, or by the subscriber typing the name in manually. At the time of writing, GPRS
con¬guration on a mobile device is still often manual and rather tedious; however, grad-
ually the process is becoming more automated, with a script ¬le containing the necessary
settings being loaded to the mobile device from the operator™s network.
When the PDP context is requested, the SGSN will check with the HLR whether or not
the APN is de¬ned there. This information is passed to the GGSN (through the selection
mode ¬eld), which will make a decision about whether or not to allow the request. The
GGSN may require that the HLR validate that the subscriber is allowed to try to gain
access to an external network via the access point. This adds further protection, so that if
the subscriber has simply typed in the APN then this request for a PDP context activation
may be rejected.
4.9 CONNECTION MANAGEMENT 145




BSS
DHCP server
Mobile
or
Device 1 sf
s
dre
d
Pa
s I evice External
ed
iev Network
etr obile
GPRS Backbone r
Nm Corp1
GS
BTS BSC G


External
GGSN
SGSN
Mobile
Network
Device 4
Corp2
GGSN IP Table
Mobile Device Access Point Mobile IP Address
mobile1 Corp1 Get External
mobile2 Corp2 173.34.56.8
mobile3 Corp2 173.34.56.9
mobile4 Corp2 173.34.56.10
... ... ...


Figure 4.48 Transparent and non-transparent modes


An APN is composed of two parts:

• APN network identity. This is mandatory and is a label for the AP. It has to conform to
DNS naming. Examples are Internet, Corp1.com, HRServer.Org5.com. The AP network
identity does not end in .gprs.
• APN operator identity. This is optional and has also to comply with the DNS fully
quali¬ed domain name convention. It consists of three labels and does end in
.gprs. The ¬rst two labels are the mobile network code followed by the mobile
country code. An example is MCCMalaysia.MNCOperator.gprs. The whole AP name
may then be Corp1.com. MCCMalaysia.MNCOperator.gprs. Note: wildcards (*) may
also be accepted as APNs but may present a security risk.



4.9.5 Charging and billing

Charging information for each of the mobile devices is collected by the SGSN and the
GGSN. The SGSN can collect charging information for the mobile device for the radio
network usage and SMS transfers via the SGSN. Both the SGSN and GGSN collect charg-
ing information on the actual data transfer, including whether it is uplink or downlink,
QoS and access point. The SGSN and GGSN generate charging data records (CDRs) and
pass them to the charging gateway, which will then consolidate these records and pass
them to the billing system. It is then the responsibility of the billing system to process
the CDRs and apply the charging policy to produce a correct charge for each transaction.
There are a huge number of different ways in which an operator can structure its charging
model. One of the challenges is then processing and presenting this information quickly
146 GENERAL PACKET RADIO SERVICE


and ef¬ciently. Unlike a phone call, one data call may generate several CDRs. The com-
plexity is further increased due to the variety of different types of transaction that may be
occurring at any given time. The operator must ensure that the subscriber is billed only
for the information they have solicited. For example, a subscriber should clearly not be
charged for receipt of an advertisement. Since the operator may be involving third-party
service providers, records of these transactions also need to be kept. This may involve
several parties, and also more than one GPRS operator, in the case of GPRS roaming. This
situation is highlighted in Figure 4.49, where a subscriber is in a V-PLMN and wishes to
connect to the home network via their H-PLMN. Here both the SGSN and remote GGSN
will generate CDRs, which will be passed to the charging gateway and on towards the
operator™s own billing system. At some stage the operators need to compare the billing
records to work out who owes what to whom. This may be performed for example at the
end of a monthly period. It can be seen that the subscriber™s traf¬c also traverses a GRX.
The GRX is probably a third party which will also require revenue for use of the network.



4.9.6 QoS over the GPRS network
To guarantee provision of QoS it may initially appear that acknowledgements between
the SGSN and GGSN should be necessary, requiring the use of TCP instead of UDP.
However, this may have an adverse effect on the network by actually slowing down
the response time if every packet is checked on this point-to-point link (SGSN to corre-
sponding GGSN), and then checked again on the end-to-end link (e.g. mobile device to
website). However, leaving the error checking and correction to the end-to-end stations
means that the packets may travel across the Internet to the other side of the world before
errors are noticed. Any request for retransmission will slow down the data transfer and
not be at all useful for many real-time applications. It is often the case that the core
network is built to be robust and is also over-dimensioned. In many cases, the equipment
will be located in the same area, perhaps even the same room, and thus it is inexpen-
sive to do this when compared to the cost of the BSS/RAN network. Building a robust
infrastructure and over-dimensioning the core network is expected to introduce suf¬cient
reliability.


Billing Consolidation
Bil
s lin
rd
co gR
e ec
R ord

<<

. 32
( 132 .)



>>