Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.060  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5…   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5…   12.6…   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…   B… 
15.3 Traffic Flow Template  15.3.0 General  15.3.1 Rules for Operations on TFTs  15.3.2 Packet Filter Attributes  15.3.3 Example Usage of Packet Filters  15.4 APN Restriction  15.5 Automatic Device Detection  15.6 Direct Tunnel Functionality  15.7 HPLMN Notification with specific indication due to SGSN initiated Bearer removal 
...

 

15.3  Traffic Flow Template  p. 331

15.3.0  General |R7|  p. 331

A TFT consists of one or more packet filters, each identified by a unique packet filter identifier. The maximum number of packet filters is specified in TS 24.008. A packet filter also has an evaluation precedence index that is unique among all packet filters that are associated with the PDP contexts that share the same PDP address and APN. This evaluation precedence index is in the range of 255 (lowest evaluation precedence) down to 0 (highest evaluation precedence). The MS manages packet filter identifiers and their evaluation precedence indexes, and creates the packet filter contents for those packet filters that are created by the MS. In 'MS/NW' mode, the GGSN/P-GW manages packet filter identifiers and their evaluation precedence indexes for those packet filters that are created by the network. A packet filter has a direction attribute, which indicates the direction of the traffic flow(s), i.e. whether they are uplink, downlink or bi-directional. A packet filter from the MS where the direction attribute is not provided describes desired downlink traffic mapping and the network shall interpret such filter as valid for both directions. For services having no downlink IP flows, the MS shall provide packet filters for uplink IP flows to enable policy control functionality as described in TS 23.203.
The state for the TFT and packet filter settings amongst all the PDP Contexts associated with one PDP address/prefix and APN pair is valid if all of the following conditions are fulfilled:
  1. there is at most one PDP Context with no associated TFT; and
  2. for 'MS/NW' mode or when the MS uses the direction attribute in 'MS_only' mode, the PDP Context established with the Secondary PDP Context Activation Procedure always has an associated TFT with at least one packet filter for the uplink direction.
The MS shall ensure that for each TFT which includes packet filters under MS control, condition 2 is fulfilled for the packet filters under MS control.
The network shall, after conducting any action necessary to recover from a detected TFT status misalignment between the MS and the network, reject any request from the MS that would violate any of these conditions.
The network shall ensure that for each TFT which includes packet filters under network control, condition 2 is fulfilled for the packet filters under network control. If the network wants to add a packet filter to the TFT of a PDP context established with the Secondary PDP Context Activation Procedure or to initiate a Network Requested Secondary PDP Context Activation Procedure, and the resulting TFT will not include any uplink packet filter among the packet filters under network control, then the GGSN/P-GW shall add a packet filter that effectively disallows any useful packet flows in uplink direction (see clause 15.3.3.4 for an example of such a packet filter).
The MS may associate a TFT with a PDP context in the Secondary PDP Context Activation procedure or the MS-Initiated PDP Context Modification procedure. The network associates a TFT with a PDP context in the Network Requested Secondary PDP Context Activation Procedure or the GGSN-Initiated PDP Context Modification procedure (if in 'MS/NW' mode). A PDP context can never have more than one associated TFT.
In 'MS_only' mode the MS may modify any TFT through the MS-Initiated PDP Context Modification procedure.
In 'MS/NW' mode the GGSN and the MS may modify any TFT through the PDP Context Modification Procedure in accordance with the restrictions described in clause 9.2.0.
A TFT associated with a PDP context is always deleted at PDP context deactivation.
The UE may use the TFT to associate the Network Requested Secondary PDP Context Activation Procedure and the GGSN-Initiated PDP Context Modification Procedure to an application and to traffic flow aggregates of the application. Therefore the GGSN shall (in the Network Requested Secondary PDP Context Activation Procedure and the GGSN-Initiated PDP Context Modification Procedure) and the P-GW shall (in the Create Dedicated Bearer Request and the Update Bearer Request messages) provide all available traffic flow description information applicable for the same EPS Bearer/PDP context (e.g. source and destination IP address and port numbers and the protocol information).
Up

15.3.1  Rules for Operations on TFTs  p. 332

The MS and GGSN shall use the TFT and packet filter identifiers in each operation for handling of the TFTs and packet filters in accordance with the restrictions described in clause 9.2.0.
When the MS or GGSN creates a new TFT, or modifies an existing TFT, it has to include at least one valid packet filter. If no valid packet filter is included in the newly created or modified TFT, the procedure used for the creation or modification of the TFT shall fail, and an error code shall be returned to the MS or GGSN respectively.
During the modification of a TFT, one or more existing packet filters can be modified or deleted, or a new packet filter can be created. In order to modify an existing packet filter, the new values for the packet filter attributes along with the packet filter identifier is sent from the MS to the GGSN, or from the GGSN to the MS. The MS may also modify the evaluation precedence index only of one or several packet filters by means of the MS-Initiated PDP Context Modification procedure. The GGSN may also modify the evaluation precedence index only of one or several packet filters by means of the GGSN-Initiated PDP Context Modification procedure.
A TFT is deleted when the associated PDP context is deactivated. For bearer control mode 'MS_only', a TFT can also be deleted by means of the MS-Initiated PDP Context Modification procedure. At any time there may exist only one PDP context with no associated TFT amongst all the PDP contexts associated with one PDP address. An attempt by the MS to delete a TFT, which would violate this rule, shall be rejected by the GGSN.
Up

15.3.2  Packet Filter Attributes  p. 333

15.3.2.0  General |R8|  p. 333

Each valid downlink- and uplink-packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique among all packet filters for one PDP address and APN pair, and at least one of the following attributes:
  • Remote Address and Subnet Mask.
  • Protocol Number (IPv4) / Next Header (IPv6).
  • Local Address and Mask.
  • Local Port Range.
  • Remote Port Range.
  • IPSec Security Parameter Index (SPI).
  • Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
  • Flow Label (IPv6).
In the list of attributes above 'Remote' refers to the external network entity, and 'Local' to the MS.
Some of the above-listed attributes may coexist in a packet filter while others mutually exclude each other. In Table 12 below, the possible combinations are shown. Only those attributes marked with an "X" may be specified for a single packet filter. All marked attributes may be specified, but at least one shall be specified.
If the parameters of the header of a received PDP PDU match all specified attribute values in a packet filter, then it is considered that a match is found for this packet filter. In this case, the evaluation procedure is aborted. Other packet filters in increasing order of their evaluation precedence index are evaluated until such match is found.
There may be potential conflicts if attribute values are combined in such a way that the defined filter can never achieve a match to a valid IP packet header. However, the determination of such conflicts is outside the scope of GPRS standardization.
Packet filter attribute Valid combination types
I II III
Remote Address and Subnet MaskXXX
Protocol Number (IPv4) / Next Header (IPv6)XX
Local Address and MaskXXX
Local Port RangeX
Remote Port RangeX
IPSec SPIX
TOS (IPv4) / Traffic Class (IPv6) and MaskXXX
Flow Label (IPv6)X
Up

15.3.2.1  Remote Address and Subnet Mask  p. 334

The Remote Address and Subnet Mask attribute of a valid packet filter shall contain an IPv4 or IPv6 address along with a subnet mask.
As an example, the remote address and subnet mask attribute to classify packets coming from all hosts within the IPv4 domain A.B.C.0/24 is {A.B.C.0 [255.255.255.0]}.

15.3.2.2  Protocol Number / Next Header  p. 334

The Protocol Number / Next Header attribute of a valid packet filter shall contain either an IPv4 Protocol Number or an IPv6 Next Header value. The value range is from 0 to 255.

15.3.2.2A  Local Address and Mask |R11|  p. 334

The Local Address and Mask attribute of a valid packet filter shall contain an IP address along with a mask.
The Local Address and Mask attribute is optional for both the MS and the network and can be used in case both the MS and network has declared support for the extended TFT filter format in the Protocol Configuration Options.

15.3.2.3  Port Numbers  p. 334

The Local Port Range and Remote Port Range attributes of a valid packet filter shall each contain one port number, or a range of port numbers. Port numbers range between 0 and 65 535.

15.3.2.4  IPSec Security Parameter Index  p. 334

The IPSec SPI attribute of a valid packet filter shall contain one SPI which is a 32 bit field.

15.3.2.5  Type of Service / Traffic Class and Mask  p. 334

The Type of Service / Traffic Class and Mask attribute of a valid packet filter shall contain either an IPv4 TOS octet or an IPv6 Traffic Class octet along with a mask defining which of the 8 bits should be used for matching.

15.3.2.6  Flow Label  p. 334

The Flow Label attribute of a valid packet filter shall contain an IPv6 flow label, which is a 20 bit field.

15.3.3  Example Usage of Packet Filters  p. 334

15.3.3.0  General |R8|  p. 334

Based on the type of traffic or the packet data network QoS capabilities, different types of packet filters can be used to classify a given PDP PDU in order to determine the right PDP context. Some examples are given below.

15.3.3.1  IPv4 Multi-field Classification  p. 334

For multi-field classification, the packet filter consists of a number of packet header fields. For example, to classify TCP/IPv4 packets originating from 172.168.8.0/24 destined to port 5 003 at the TE, the following packet filter can be used:
  • Packet Filter Identifier = 1;
  • IPv4 Source Address = {172.168.8.0 [255.255.255.0]};
  • Protocol Number for TCP = 6; and
  • Destination Port = 5 003.

15.3.3.2  IPv4 TOS-based Classification  p. 335

For TOS-based classification, the packet filter consists of only the TOS octet coding. For example to classify IPv4 packets marked with TOS coding 001010xx, the following packet filter can be used:
  • Packet Filter Identifier = 3;
  • Type of Service / Traffic Class = 00101000 and Mask = 11111100.

15.3.3.3  IPv4 Multi-field Classification for IPSec Traffic  p. 335

For multi-field classification of IPSec traffic, the packet filter contains the SPI instead of the port numbers that are not available due to encryption. If IPSec (ESP) was used with an SPI of 0x0F80F000, then the following packet filter can be used:
  • Packet Filter Identifier = 4;
  • Protocol Number for ESP = 50; and
  • SPI = 0x0F80F000.

15.3.3.4  Services with IP flows in only one direction |R10|  p. 335

For services with no uplink IP flows, a dummy uplink packet filter can be provided by the network to avoid that the UE uses the PDP context for uplink traffic that is expected on the PDP context without any uplink packet filter. For example that can be done by assigning the remote port "9", which is the "discard" port, i.e. the following packet filter can be used:
  • Packet Filter Identifier = 5;
  • Packet Filter Direction = uplink only; and
  • Remote port = 9 (the discard port).
Up

15.4  APN Restriction |R6|  p. 335

The support for APN Restriction and Maximum APN Restriction at the SGSN is optional and an APN Restriction value may be configured for each APN in the GGSN or PGW. The support for reception, storage, and transfer of APN Restriction is required for an S4-SGSN. It is used to determine, on a per MS basis, whether it is allowed to establish PDP Contexts or EPS bearers to other APNs.
Maximum APN Restriction Value Type of APN Application Example APN Restriction Value allowed to be established
0No Existing Contexts or RestrictionAll
1Public-1WAP or MMS1, 2, 3
2Public-2Internet or PSPDN1, 2
3Private-1Corporate (e.g. who use MMS)1
4Private-2Corporate (e.g. who do not use MMS)None
During the PDP Context Activation procedure or the default bearer activation (for connectivity through S4), the GGSN or PGW may compare the APN Restriction of the PDP Context being set up with the Maximum APN Restriction received from the SGSN to decide whether this activation is accepted. The Maximum APN Restriction is the most restrictive value of the APN Restriction (highest number) from all already active PDP Contexts. The APN Restriction is transferred at PDP Context activation to the SGSN.
The APN Restriction for each PDP context, if available, shall be transferred either from the GGSN or PGW to the new SGSN during inter-SGSN changes (e.g. SRNS Relocation and Routeing Area Update) or from the old SGSN in case both SGSNs use S16 for connectivity. The new SGSN determines the maximum APN Restriction using the APN Restriction contained in the Update PDP Context Response message(s) received from the GGSN(s) or PGW(s).
During the PDP Context Modification procedure (via the APN Restriction received from the GGSN or PGW) and inter-SGSN changes, the SGSN shall verify if there are PDP contexts to different APNs that violate valid combinations based on the APN Restriction. If a violation is detected, the SGSN shall release PDP contexts until a valid combination results and shall send appropriate error causes to the MS. Which PDP contexts are released is network operator configurable and the SGSN may perform one of the following actions, using the SGSN-Initiated PDP Context Deactivation procedures in clause 9.2.4.2, until a valid combination remains or no further actions are possible:
  1. Deactivate the most restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate error cause to the MS,
  2. Deactivate the least restrictive, as dictated by the APN Restriction value, PDP Context sending an appropriate error cause to the MS,
  3. Deactivate PDP Contexts in no particular order sending an appropriate error cause to the MS.
During PDP Context Activation procedure or default bearer activation (for connectivity through S4) for emergency, GGSN or PGW shall ignore APN Restriction. During PDP Context Modification procedure (via the APN Restriction received from the GGSN or PGW) and inter SGSN changes, the SGSN shall not deactivate bearer(s) with emergency ARP, if any, to maintain valid APN combination. Same restriction also applies to procedures in TS 23.401.
Up

15.5  Automatic Device Detection |R6|  p. 336

The Automatic Device Detection (ADD) function is an optional feature that allows the network to be updated with the current User Equipment identity (IMEISV). This, for example, enables the network to configure the subscriber's equipment. A device management system can retrieve the IMEISV either from SGSN or from HLR, or be triggered by a changed IMEISV in either SGSN or HLR. However, the device management system and the mechanism to send the configuration to the terminal are outside the scope of 3GPP specifications.
When the ADD function is supported, the SGSN obtains and stores the IMEISV from the MS at GPRS Attach and at Inter-SGSN Routing Area Update procedures when the old SGSN does not provide the IMEISV. The SGSN uses either the GMM Identification procedure or the GMM Authentication and Ciphering procedure to obtain the IMEISV (TS 24.008). Equipment checking is independent from IMEISV retrieval for ADD. If the IMSI was not previously registered in the SGSN, the SGSN includes the IMEISV in the Update Location message to the HLR. If the IMSI was already registered, the SGSN compares the IMEISV retrieved from the UE with the one stored in SGSN MM context and sends the IMEISV in the Update Location to the HLR if these are different. The MAP parameter Skip Subscriber Data Update should be included in this case to avoid unnecessary signalling, i.e. Cancel Location and Insert Subscriber Data unnecessarily being sent to SGSN.
For the purposes of ADD the IMEISV is transferred on the Gs interface as part of the combined GPRS/IMSI attach procedure.
For further information on the Automatic Device Detection function, please refer to TS 22.101 and TS 23.012.
Up

15.6  Direct Tunnel Functionality |R7|  p. 336

Direct Tunnel is an optional function in Iu mode that allows the SGSN to establish a direct user plane tunnel between RAN and GGSN (for connectivity with GGSN through Gn/Gp) or S-GW (for connectivity through S4) within the PS domain.
A Direct Tunnel capable SGSN shall have the capability to be configured on a per RNC and per GGSN or S-GW basis whether or not it can use a direct user plane connection.
The SGSN handles the control plane signalling and makes the decision when to establish Direct Tunnel. When the RAB assigned for a PDP context is released (i.e. the PDP context is preserved) the GTP-U tunnel is established between the GGSN (for connectivity with GGSN through Gn/Gp) and SGSN in order to be able to handle the downlink packets.
Reproduction of 3GPP TS 23.060, Fig. 15.6-1: IDLE mode handling for Gn/Gp connectivity
Figure 15.6-1: IDLE mode handling for Gn/Gp connectivity
Up
Reproduction of 3GPP TS 23.060, Fig. 15.6-2: IDLE mode handling for S4 connectivity
Figure 15.6-2: IDLE mode handling for S4 connectivity
Up
Direct Tunnel shall not be used in following traffic cases:
  1. In roaming case for connectivity with GGSN through Gn/Gp only
    • The SGSN needs to know whether the GGSN is in the same or different PLMN.
  2. If the SGSN is connected with a GGSN through Gn/Gp and the SGSN has received CAMEL Subscription Information in the subscriber profile from the HLR.
    • If Direct Tunnel is established then volume reporting from SGSN is not possible as the SGSN no longer has visibility of the User Plane. Since a CAMEL server can invoke volume reporting at anytime during the life time of a PDP Context, the use of Direct Tunnel shall be prohibited for a subscriber whose profile contains CAMEL Subscription Information.
  3. GGSN does not support GTP protocol version 1.
Up

15.7  HPLMN Notification with specific indication due to SGSN initiated Bearer removal |R11|  p. 337

When initiating a Delete PDP context procedure, the SGSN shall add an appropriate cause code facilitating the operator of the GGSN/P-GW to take appropriate action (e.g. Alarm, O&M action by operator's management network) if needed.
Up

Up   Top   ToC