7. RESULTADOS
7.2. Simulación de la sala de calderas
7.2.3. Simulación uno Flujo cruzado
Once the mobile device has registered with the mobile network, it cannot start to send and receive data over the packet core until it has established a session, which is known as hav- ing a packet data protocol context (PDP context). A mobile device has to be in the ready mode to activate a PDP context; however, the PDP context will continue to be present if the mobile device moves to the standby state. This is to allow a subscriber to retain the same IP address, even if they have not generated or received any traffic for some time.
This process of PDP context activation results in the mobile device obtaining an IP address. This IP address can be given either by the operator’s network or by an external network. To obtain an IP address the user may select a particular service on the mobile device by scrolling through a menu. For example, the menu may have ‘Internet’ or ‘home Intranet’ as an item. This request for a connection will be passed through the network to the SGSN. The SGSN has to locate the correct GGSN, which will be used to route the data to the correct external network. Note that there may be more than one GGSN connected to the external network for load sharing and redundancy. To find the GGSN, the SGSN will contact a DNS server within the operator’s private network; the DNS server will return the IP address of the GGSN where the particular connection (known as an
access point) is located. A GGSN can have a number of access points, i.e. connections, to different external networks. The SGSN can now contact the GGSN and ask for a PDP context to be granted for this user. Figure 4.40, illustrates this process.
The PDP context ensures that a GPRS Tunnel is set up between the SGSN and GGSN for the sole use of this user. An IP address for the mobile device will also be given to the mobile station at this time. It should be noted that the GGSN may not be in the same network as the SGSN. This is the case when the mobile is in a visited or V-PLMN and may wish to connect to an access point in its H-PLMN. Figure 4.41 illustrates the end points
Source address : 10.1.2.123 Dest address : 10.1.2.231 SGSN CONTEXT REQUEST - Version number: 1 (1h) - Protocol type: 1 (1h) - Extension header flag: 0 (0h)
- Sequence number flag: 1 (1h) - N-PDU number flag: 0 (0h) - Message Type: 50 (SGSN CONTEXT REQUEST) - Header Length: 30 (1eh) - Tunnel endpoint id: 0 (00000000h)
- Sequence number: 13 (dh) - No extension header Routeing Area Identity - MCC : 511
- MNC : 044 - LAC : 38 (0026h) - RAC : 1 (01h) TLLI
- TLLI : foreign TLLI 2325850897(8AA1AB11h) MS Validated : no Tunnel Endpoint Iden CP - id: 0 (00000000h)
SGSN Address for Control Plane - length: 4 (4h) - Ipv4 Address: 10.1.2.123 NEW SGSN Source address : 10.1.2.231 Dest address : 10.1.2.123 SGSN CONTEXT RESPONSE - Version number: 1 (1h) - Protocol type: 1 (1h) - Extension header flag: 0 (0h) - Sequence number flag: 1 (1h) - N-PDU number flag: 0 (0h) - Message Type: 51 (SGSN CONTEXT RESPONSE)
- Header Length: 117 (75h) - Tunnel endpoint id: 0 (00000000h)
- Sequence number: 13 (dh) - No extension header Cause
- acceptance: request accepted IMSI
- MCC : 511
- NMSI : 232134628909 Tunnel Endpoint Iden CP - id: 13 (0000000Dh) MM Context
- length : 17 (0011h) - security mode : GSM key and triplets
- CKSN : 1 (01h) - Used Cipher : GEA/2
- KC : FF 03 91 AC 02 8F E5 54 - split PG Cycle value: 7 - DRX cycle length coefficient not specified
- split pg cycle on CCCH not supported
- max. 2 sec non-DRX mode after transfer state
- MS Network capability: - Encryption algorithm GEA/1 available
- SM capabilities via dedicated channels supported
- SM capabilities via GPRS channels supported
- Use of default alphabet over UCS2 prefered
- Capab. of ellipsis notation and phase 2 error handling
- The ME does not support SoLSA - Mobile station supporting earlier versions of the protocol - Mobile station does not support BSS packet flow procedures - encryption algorithm GEA/2 available
- encryption algorithm GEA/3 not available
- encryption algorithm GEA/4 not available
- encryption algorithm GEA/5 not available
- encryption algorithm GEA/6 not available
- encryption algorithm GEA/7 not available - container length : 0 (00h) PDP Context - length: 67 (0043h) - NSAPI: 5 (05h) - order : No - VAA : No - SAPI: 5 (05h) - QoS Sub - length 12 (0Ch) - allocation/retention priority 2 (02h) - unacknowledged GTP; acknowledged OLD SGSN
LLC and RLC, protected data - delay class 4 (best effort) - precedence class: normal priority
- peak throughput : up to 256 000 octet/s
- mean throughput : best effort - traffic class : subscribed - delivery order: with delivery order ('yes')
- delivery of erroneous SDUs: not delivered
- maximum SDU size: 1500 - maximum bit rate for uplink: 2048 kbps
- maximum bit rate for downlink: 2048 kbps
- residual BER: 1*10-5 - SDU error ratio: 1*10-6 - transfer delay: subscribed (MS only)
- traffic handling priority: subscribed
- guaranteed bit rate for uplink: subscribed (MS only) - guaranteed bit rate for downlink: subscribed (MS only) - QoS REQ
- length 4 (04h)
- allocation/retention priority 0 (00h)
- subscribed reliability class - subscribed delay class - precedence class: subscribed - peak throughput : subscribed peak throughput
- mean throughput : Subscribed - QoS NEG - length 4 (04h) - allocation/retention priority 0 (00h) - unacknowledged GTP; acknowledged LLC and RLC, protected data
- delay class 4 (best effort) - precedence class: normal priority
- peak throughput : up to 256 000 octet/s
- mean throughput : best effort - SND : 0 (0000h)
- SNU : 4 (0004h) - send N-PDU : 0 (00h) - receive N-PDU : 4 (04h) - uplink TEI Control Plane: 16777296 (01000050h) - uplink TEI Data I: 15802628 (00F12104h)
- PDP Context Identifier: 10 (0Ah)
- PDP type organisation : reserved value 10 (0Ah) - PDP type number : 3 (03h) - PDP address length: 2 (02h) - PDP address: : 040A - GGSN address for control plane:
- length 10 (0Ah) - address: : [Abridged] - GGSN address for User Traffic: - length 108 (6Ch) - address: : [Abridged] - transaction identifier 0 (000h) Unknown IE: 0 (0h) Source address : 10.1.2.123 Dest address : 10.1.2.231 SGSN CONTEXT ACKNOWLEDGE - Version number: 1 (1h) - Protocol type: 1 (1h) - Extension header flag: 0 (0h)
- Sequence number flag: 1 (1h) - N-PDU number flag: 0 (0h) - Message Type: 52 (SGSN CONTEXT ACKNOWLEDGE) - Header Length: 19 (13h) - Tunnel endpoint id: 13 (0000000Dh)
- Sequence number: 13 (dh) - No extension header Cause
- acceptance: request accepted Tunnel Endpoint Iden Data II - NSAPI: 5(5h)
- id: 11 (0000000Bh) SGSN Address for user traffic - length: 4 (4h)
- Ipv4 Address: 10.1.2.123 NEW SGSN
BSC BTS BSS Mobile Station SGSN GPRS Backbone GGSN External Network Corp1 HLR Subscr iption Inf ormation DNS Lookup Table Access Point Corp1 Corp2 Corp3 GGSN IP Address 10.1.1.40 10.1.1.40 10.1.1.40 DNS Name Lookup External Network Corp3 External Network Corp2
Figure 4.40 PDP context activation
BSC BTS BSS Mobile Station MSC GSM Backbone G-MSC PSTN Intranet 1 Intranet 2 Intranet 3 Internet GTP tunnel GRX SGSN GPRS Backbone Operator 1 GGSN Home Intranet SGSN GPRS Backbone Operator 2 GGSN GTP tunnel Figure 4.41 GTP tunnel
of the tunnel between SGSN and GGSN in the local network, and also a tunnel through the global roaming exchange (GRX) to another PLMN network in a different country. Note also that the GGSNs can have a number of access points to external networks.
Once a PDP context has been activated, the user can then use the services provided by the particular access point. For example, if the user with a device possessing the
appropriate application software connected to the access point ‘Internet’ then they would be able to ‘surf the web’. Suppose the user requests a web page from a server, ‘get page request www.orbitage.com/default.htm’. The web server will respond with the web page, and the destination IP address from the web server’s point of view will be the mobile device which made the initial request. This IP address will be routed back across the Internet to the GGSN. The GGSN now needs to send it to the correct SGSN for final delivery to the mobile device. It does this by cross-referencing the IP address with all of the tunnel identifiers it has; hopefully there will be a match. The tunnel identifier actually comprises the IMSI of the mobile device and is therefore unique. As long as the IP address arriving at the GGSN is also unique, there should be no problem with mapping one onto the other.
The GPRS tunnel now transfers the IP packet to the SGSN. Once the data arrives at the SGSN, the IP packet is removed from the GPRS tunnel. The SGSN now needs to resolve the IP address into the P-TMSI address of the mobile device. The unique connection from the SGSN to the mobile device is known as the temporary logical link identifier
(TLLI) and comprises the P-TMSI of the mobile device. The TLLI uniquely identifies the mobile device within an RA. It is sent in all packet transfers. The SGSN has a database of P-TMSI to IMSI mapping which will identify the correct mobile device to which it should deliver the response.
Figure 4.42 shows how the IP packet is transported from the web server back to the mobile device. The GTP header (containing the IMSI) is routed to the correct SGSN via the underlying protocol (another IP network). Once the packet reaches the SGSN, the GTP header is discarded and a new TLL header is added. It is possible that between the SGSN and mobile device, the IP packet may be broken into smaller sections and carried by separate LLC frames. It is actually the SNDCP that deals with this segmentation and reassembly.
The IP packet is now transported to the mobile station using a number of LLC layer packets. Between the SGSN and the BSC, the LLC is itself carried over a frame relay network. At the BSC the LLC packets are extracted from the frame relay packets and transported to the correct BTS, usually over the TDM slots of an E1 or T1 line. The BSC will segment the LLC frames into a number of smaller RLC/MAC frames. These will be transported via the BTS to the mobile device, where they will be grouped to reconstruct the original LLC frame. Once the BTS has received the RLC/MAC frames, it then transmits them across the air interface to the mobile device. When the LLC packets
BSC BTS BSS Mobile Station SGSN GPRS Backbone GGSN Internet
IP Get Page Reply
GTP HDR IP Get Page Reply
LLC HDR IP Get Pa LLC HDR Get Reply
arrive at the mobile device, the IP packet is reassembled, and processed by the application on the device.
A mobile device may have a number of PDP contexts active at any one time. These may or may not be to the same GGSN, but are given separate tunnel identities, and the mobile device will have a number of addresses associated with it, for example IP addresses. It will have one address for each primary PDP context activated. When a PDP context exists and another context is defined which uses the same address, and possibly some of the same context information, this is referred to as a secondary context. The secondary PDP context procedure can be used to make an alternative connection to an already active context but with different QoS. The PDP address and other PDP context information already established are reused. Since an access point must have been defined for the primary context, procedures for access point name (APN) selection and PDP address negotiation are not executed. The secondary PDP context will use the same IP address as the primary context; it will be identified through a unique transaction identifier and its own NSAPI. As an example, consider a videoconferencing application. This can consist of a video stream and a whiteboarding application. Here, the video traffic presents quite stringent QoS requirements, whereas the whiteboarding is non-real-time and thus has looser QoS demands, since it can tolerate delays.
Figure 4.43 illustrates the procedures for a mobile-originated PDP context activation. 1. The mobile device sends the PDP request, which contains the NSAPI, PDP type, PDP
address, APN, QoS requirements and any PDP configuration options. The NSAPI identifies the service access point in the mobile device, which will be dealing with this specific PDP context. The PDP type indicates if this is an X.25 or IP connection6
and the PDP address indicates the actual address. In the case of IP this will be an IP address for the mobile device. If the mobile device does not have a static IP address
MS
Create PDP context Reponse BSS Packet Flow
Context Procedures
Create PDP Context Request
Activate PDP Context Response
GGSN SGSN
BSS
Security Functions Activate PDP Context Request
1 5 4 3 2 6 Figure 4.43 UE-originated PDP context activation
6X.25 was originally supported in GTP version 0 but has been removed from GTP version 1.
then this field will consist of 0.0.0.0 and the GGSN will allocate the IP address. It practical situations it is more common that dynamic addresses are allocated since this provides greater flexibility. The APN, described in Section 4.9.4, is the mobile operator’s external connection point. This is a text name and has local significance only. Examples of this could be Internet, Corporation-1 etc. Each PDP context may have a different QoS requirement; perhaps higher QoS may mean that the subscriber has to pay a premium price. The options field is transparently transported through the SGSN to the GGSN where optional parameters may be implemented.
2. Once the SGSN has received the request it will most likely invoke the security procedures to authenticate the mobile subscriber and device. These are very similar to the GSM security procedures. The SGSN will validate the subscriber’s request with those permitted through the subscription records in the HLR. For example, if the subscriber has asked for a higher level of QoS than they have subscribed for in their service level agreement, then this QoS value may be reduced. Also checked is the use of static IP addresses, as well as whether the requested APN is defined in the HLR for that subscriber.
3. The SGSN generates a TEID consisting of the IMSI and NSAPI or a link to it, and checks whether it has the resources available to allow the requested QoS. If not, it may restrict the requested QoS. The SGSN locates a GGSN which has access to the access point and sends acreate PDP context request. This message consists of the TEID, MSISDN, selection mode (as described in Section 4.9.4 for the APN), PDP type, PDP address, APN, negotiated QoS, charging characteristics and any PDP configuration options. The charging characteristics are checked with the HLR to ascertain how the subscriber will be billed for this connection. The GGSN will create a new entry in its PDP context table and generate a charging ID. The GGSN may also restrict the QoS for this connection if it does not have the required resources available. If the mobile device has been allocated an IP address then this may be configured by the GGSN (see Section 4.9.3).
4. The GGSN will send acreate PDP context response to the SGSN including the charging ID and any modifications to the QoS.
5. The BSS packet flow procedures may be executed to ensure that the QoS requirements are met. All the packet flows related to a single mobile device are stored in a specific BSS context. Individual contexts are identified by a unique packet flow identifier which is allocated by the SGSN. As was discussed, there are three packet flows that are predefined:SMS, signalling andbest effort. In these cases, no negotiation of BSS packet flow contexts is required. Both the best effort and SMS packet flows can be assigned to a PDP context and PDP data packets will be carried across the BSS with the same QoS as the predefined flows. To ensure QoS is guaranteed, the SGSN divides the transfer delay between the BSS and core network part. It can do this since it can estimate the transfer delay over the core network to the GGSN. The SGSN can then convert the maximum SDU size, SDU error ratio, residual bit error ratio, maximum bit rate, guaranteed bit rate and thus the transfer delay to that applicable for this transfer. The SGSN inserts the NSAPI and the GGSN address into its PDP context and selects the radio priority and packet flow ID based on the QoS negotiated.
MS
PDP Notification Request
PDP Context Activation Procedures
Send Routing info for GPRS Ack
Request PDP Context Activation
GGSN SGSN
PDP PDU Send Routing info for GPRS
HLR PDP Notification Response 1 6 5 4 3 2
Figure 4.44 GGSN-originated PDP context activation
6. Finally, theactivate PDP context accept message is sent to the mobile device from the SGSN, indicating that the request has been accepted.
A network-requested PDP context activation procedure is illustrated in Figure 4.44. Here a PDU arrives at the GGSN from an external source for a mobile device. This system only works when the GGSN knows the IP address of the mobile device, i.e. the mobile device has a static IP address.
1. If there is no PDP context activated then the GGSN may query the HLR for connection information. To limit the number of queries to the HLR, themobile station not reachable for GPRS flag (MNRG)message may be set in the GGSN. In this case the GGSN will not query the HLR. Thesend routing information for GPRS
message will request the IMSI of the intended recipient.
2. The HLR will respond with the IMSI and the SGSN address of the mobile device in thesend routing information for GPRS acknowledge message.
3. Once the GGSN has this information, it can send aPDU notification request
message to the SGSN which contains the IMSI number of the mobile device, the APN, PDP type and PDP address of the mobile device.
4. ThePDU notification response message is returned to the GGSN to indicate that it will try to reach the mobile device. If the mobile device is not known then an unsuccessful response such asIMSI not known may be returned to the GGSN. 5. The SGSN can send arequest PDP context activation message to the mobile device
to request the device to activate the indicated PDP context.
6. This is followed by the regular PDP context activation procedures as highlighted in Figure 4.43.
The issues with regard to this type of mobile-terminated data access stretch beyond the technical capabilities of the network. Allowing external sources to activate a PDP context presents a number of consequences, some of which may be undesirable for both
subscriber and network operator. In comparison, the Internet is essentially apull medium, meaning that information is accessed by the user, and can not generally be network originated. One exception to that is unsolicited email, or spam, which is already presenting problems in both fixed-line and mobile networks. If information push is permitted, it is difficult to identify which traffic is wanted and which is not. The central issue is