USOO7649837B1
`
`(12) United States Patent
`Puuskari
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,649.837 B1
`Jan. 19, 2010
`
`(54) CONTROL OF GATEWAY SUPPORT NODE
`SELECTION
`
`(75) Inventor: Mikko Puuskari, Helsinki (FI)
`(73) Assignee: Nokia Networks Oy, Espoo (FI)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`09/869,247
`
`(21) Appl. No.:
`
`(22) PCT Filed:
`(86). PCT No.:
`
`Dec. 28, 1999
`PCT/F99/O1083
`
`S371 (c)(1),
`Sep. 14, 2001
`(2), (4) Date:
`(87) PCT Pub. No.: WO00/41414
`PCT Pub. Date: Jul. 13, 2000
`Foreign Application Priority Data
`(30)
`Dec. 31, 1998
`(FI)
`...................................... 98.2855
`(51) Int. Cl.
`(2006.01)
`HD4L 2/26
`(52) U.S. Cl. ....................... 370/225; 370/252; 370/331;
`37O/4O1
`(58) Field of Classification Search ................. 370/328,
`370/338, 401, 216-218, 229, 230, 235, 237,
`370/252,310,349, 402, 225, 262
`See application file for complete search history.
`References Cited
`
`(56)
`
`U.S. PATENT DOCUMENTS
`5,752,162 A
`5/1998 Sawyer et al.
`
`5,892,819 A * 4/1999 Stumer .................. 379,211.02
`6,070,192 A * 5/2000 Holt et al. ................... 709,227
`6,104,929 A
`8/2000 Josse et al. .................. 455,445
`6,233,458 B1* 5/2001 Haumont et al. ............ 455,445
`6,535,507 B1 * 3/2003 Lietal. ............
`... 370,356
`6,608,832 B2* 8/2003 Forslow .....
`... 370,353
`6,636,502 B1 * 10/2003 Lager et al. ....
`... 370,352
`6.738,909 B1* 5/2004 Cheng et al. ......
`... 370, 401
`6,829,242 B2 * 12/2004 Davison et al. ...
`... 370,231
`6,937,566 B1* 8/2005 Forslow ............
`... 370,352
`2001/0055299 A1* 12/2001 Kelly ...............
`... 370,409
`2003/0O26273 A1
`2/2003 Davison et al. ...
`2007/009 1862 A1* 4/2007 Ioannidis .................... 370,338
`2007. O195791 A1* 8, 2007 Bosch et al. ........... 370,395.52
`20070213058 A1* 9, 2007 Shaheen ..................... 455,436
`
`- - - - - - T26/3
`
`FOREIGN PATENT DOCUMENTS
`
`WO
`WO
`
`WO98,59468
`WOOOf 14981
`
`12/1998
`3, 2000
`
`* cited by examiner
`Primary Examiner Chi H. Pham
`Assistant Examiner Shick Hom
`(74) Attorney, Agent, or Firm—Pillsbury Winthrop Shaw
`Pittman, LLP
`
`(57)
`
`ABSTRACT
`
`The invention relates to controlling selection of a gateway
`Support node of a packet-switched network. The invention
`includes defining at least one condition for the gateway Sup
`port node. When the condition is fulfilled, another gateway
`Support node is more Suitable for transmitting packets. When
`fulfillment of the condition is detected, a first message indi
`cating the other gateway Support node is transmitted to the
`serving Support node.
`
`12 Claims, 4 Drawing Sheets
`
`MS
`
`
`
`SGSN
`
`GGSN1
`
`GGSN2
`
`DB
`
`Ex.1014
`APPLE INC. / Page 1 of 11
`
`

`

`U.S. Patent
`
`Jan. 19, 2010
`
`Sheet 1 of 4
`
`US 7,649.837 B1
`
`FIG. 1
`(PRIOR ART)
`
`FIG.6
`
`SGSN
`
`
`
`GGSN2, ... . . . . . . GGSN3
`
`
`
`new tunnel
`
`deletion
`
`Ex.1014
`APPLE INC. / Page 2 of 11
`
`

`

`U.S. Patent
`
`Jan. 19, 2010
`
`Sheet 2 of 4
`
`US 7,649.837 B1
`
`214
`
`215
`
`send negative response
`
`216
`
`PDP COntext
`
`delete PDP Context
`
`
`
`
`
`205
`
`
`
`
`
`Send positive response
`2O6
`
`
`
`PDP Context
`
`update PDP context
`
`l O
`Create PDP Context
`
`monitor
`
`2O7
`
`209
`
`yes
`
`210
`
`FIG.2
`
`retrieve GGSN address
`
`
`
`
`
`delete PDP COn text
`
`208
`
`211
`
`212
`
`213
`
`Ex.1014
`APPLE INC. / Page 3 of 11
`
`

`

`U.S. Patent
`
`Jan. 19, 2010
`
`Sheet 3 of 4
`
`US 7,649.837 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`negative response received
`
`301
`
`3O2
`O
`
`PDP
`Context
`active
`2
`yeS
`
`ra 303
`
`FIG.3
`
`304 1.
`
`312
`
`GGSN
`address?
`
`
`
`
`
`O
`
`unused
`addresses?
`
`
`
`O
`
`yes
`
`305
`O
`
`3S yes
`
`yes
`313
`N
`select the topmost one
`seat --
`U 314
`
`ra- 3O6
`
`Send Create request
`
`308
`
`9
`30 J
`yes
`negative?
`
`
`
`O
`
`activate PDPCOntext
`
`establish tunnel
`
`
`
`
`
`
`
`31 O
`
`
`
`315
`
`
`
`
`
`Ex.1014
`APPLE INC. / Page 4 of 11
`
`

`

`U.S. Patent
`
`Jan. 19, 2010
`
`Sheet 4 of 4
`
`US 7,649.837 B1
`
`MS
`
`SGSN
`
`GGSN1
`
`GGSN2
`
`DB
`
`it 4-9
`
`4-11
`
`SGSN
`
`
`
`GGSN2
`
`GGSN3
`
`5-2
`
`removal,
`address
`
`
`
`deletion
`
`neW tunnel
`
`5-6
`
`-
`
`FIG.5
`
`Ex.1014
`APPLE INC. / Page 5 of 11
`
`

`

`US 7,649,837 B1
`
`1.
`CONTROL OF GATEWAY SUPPORT NODE
`SELECTION
`
`This application is the National Stage of International
`Application PCT/FI99/01083 filed Dec. 28, 1999 which des
`ignated the U.S. and that International Application was filed
`in English.
`
`BACKGROUND OF THE INVENTION
`
`10
`
`2
`over the radio interface and further through the base station
`subsystem with the support node SGSN to the service area of
`which the cell belongs.
`The gateway GPRS support node GGSN connects the
`GPRS service of an operator to other data networks PDN,
`such as an IP network (Internet, Intranet) or X.25 network.
`The GGSN includes the routing information on GPRS sub
`scribers, i.e. SGSN addresses and addresses of the external
`network related to the PDP contexts. The GGSN functions as
`a router between the external address and the internal routing
`information (e.g. SGSN). The GGSN may also transmit pack
`ets from one mobile station to another within the network.
`A subscriber to the GPRS service has one or more external
`PDP addresses available. The PDP address is used for iden
`tifying a certain user context from the external network. A
`mobile station attached to the GPRS service may receive
`and/or transmit data packets with a certain PDP address pro
`vided that a corresponding packet data protocol PDP context
`is activated in the mobile station, serving Support node and
`gateway support node. Activation of the PDP context estab
`lishes a tunnel between the support node SGSN serving the
`mobile station and the gateway support node GGSN. The
`tunnel is established using a GPRS tunneling protocol GTP
`between the SGSN and the GGSN. The prior art tunneling
`protocol is disclosed in ETSI specification GSM 09.60, ver
`sion 6.2.0 (Digital cellular telecommunications system
`(Phase 2+); General Packet Radio Service (GPRS); GPRS
`Tunneling Protocol (GTP) across the Gn and Gp Interface).
`The tunnel is established in such a manner that the SGSN
`sends a “Create PDP Context request to the GGSN which
`either accepts or rejects it. If the GGSN accepts the create
`request, the tunnel is established. If the GGSN rejects the
`create request, the SGSN either sends the create request to the
`next GGSN (if it has information on it) or informs the mobile
`station of the fact that the context cannot be activated. Selec
`tion of the next GGSN by the serving support node SGSN is
`based on Static lists which are maintained e.g. in the internal
`name server of the GPRS service. After the tunnel has been
`established, the gateway support node GGSN can only either
`reject or accept any update requests made by the serving
`Support node or request the serving Support node to remove
`the tunnel.
`A problem related to the arrangement described above is
`that the gateway Support node GGSN cannot at any stage
`indicate another gateway Support node to the serving Support
`node which would be a more Suitable gateway Support node.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`The invention relates to controlling selection of a gateway
`Support node in a packet-switched network, and particularly
`to controlling selection of a packet-switched gateway Support
`node in a mobile communication network.
`Mobile communication networks function as effective
`access networks which provide the users with access to the
`actual data networks for mobile data transmission. Mobile
`data transmission is supported particularly well by digital
`mobile communication systems, such as the pan-European
`mobile communication system GSM (Global System for
`Mobile Communication). In this application the term data
`refers to any information transmitted in a digital telecommu
`nications system. Such information may comprise digitally
`encoded audio and/or video, inter-computer data traffic, tele
`fax data, short sections of program codes, etc.
`General packet radio service GPRS is a new service for the
`GSM system and one of the issues standardized by ETSI
`(European Telecommunication Standard Institute) in GSM
`30
`phase 2+. The GPRS service enables packet data transmission
`between mobile data terminals and external data networks,
`while the GSM network functions as an access network. One
`of the requirements set on the GPRS service is that it should
`cooperate with different external data networks, such as the
`Internet or X.25 networks. In other words, the GPRS service
`and the GSM network should be able to serve all users regard
`less of the type of the data network they want to attach to via
`the GPRS Service. This means that the GPRS Service must
`Support and process different network addresses and data
`packet forms. Processing of data packets also comprises rout
`ing of them in a packet radio network. Furthermore, the users
`should be able to roam from the home GPRS network to a
`visiting GPRS network the operator of which may have a
`backbone network Supporting a different protocol (e.g.
`CLNP) than the home network (e.g. X.25). The logical net
`work architecture of the GPRS service is illustrated in FIG.1.
`FIG. 1 illustrates the network architecture of a GPRS ser
`vice at a general level because the detailed structure of the
`network is irrelevant to the invention. The GPRS service
`comprises an access network which provides radio access and
`is the base station subsystem BSS of the GSM system in FIG.
`1, and support nodes of the GPRS service for packet-switched
`transmission of packet-switched data between a packet net
`work PDN and a mobile station MS. The support nodes
`include a serving GPRS support node SGSN and a gateway
`GPRS support node GGSN. These different support nodes
`SGSN and GGSN are interconnected by a backbone network.
`It should be noted that the functionalities of the SGSN and the
`GGSN can also be physically combined into the same net
`work node. Logically the nodes are, however, separate nodes.
`The serving GPRS support node SGSN serves the mobile
`station MS. Each support node SGSN manages a packet data
`service within the area of one or more cells in a cellular packet
`radio network. For this purpose, each support node SGSN is
`typically connected to a base station subsystem BSS. The
`mobile station MS in a cell communicates with a base station
`
`50
`
`55
`
`60
`
`65
`
`BRIEF DESCRIPTION OF THE INVENTION
`
`An object of the invention is to provide a method and an
`apparatus implementing the method to eliminate the above
`mentioned problems. The objects of the invention are
`achieved with a method, telecommunications system and
`Support nodes of a packet network which are characterized by
`what is disclosed in the independent claims. The preferred
`embodiments of the invention are described in the dependent
`claims.
`The invention is based on the idea that the gateway Support
`node Suggests another more Suitable gateway Support node
`with which the tunnel should be established to the serving
`Support node. The gateway Support node may make the Sug
`gestion either when it rejects the request for establishing a
`tunnel or when the conditions change so that it is practical to
`remove the existing tunnel.
`An advantage of the method, system and Support nodes of
`the invention is that the operator can distribute the load
`dynamically to the gateway Support nodes in the network and
`
`Ex.1014
`APPLE INC. / Page 6 of 11
`
`

`

`US 7,649,837 B1
`
`3
`transfer the tunnel between the SGSN and the gateway Sup
`port node to another gateway support node depending on the
`conditions, e.g. in connection with handover of serving Sup
`port nodes.
`In a preferred embodiment of the invention the messages
`which are sent to the serving support node and indicate the
`most suitable gateway support node are response messages to
`the Create PDP Context request. A further advantage of this
`embodiment is that it is extremely simple to implement: one
`parameter/attribute is added to an existing message. This
`enables gradual introduction of the feature into a network,
`and thus both old serving support nodes lacking the inventive
`functionality and new serving support nodes with the func
`tionality of the invention can be used simultaneously in the
`network without interfering with its function.
`In a preferred embodiment of the invention where the end
`of an existing tunnel is to be transferred from one gateway
`support node to another, the tunnel is removed in the gateway
`support node only in response to a positive acknowledge
`ment. A further advantage of this embodiment is that packets
`are not lost if there has not been time to establish a tunnel
`between the other gateway support node and the serving
`support node. This embodiment also allows to ensure at least
`satisfactory transmission of packets.
`
`10
`
`15
`
`4
`described in greater detail above. The structure and function
`of the GSM system are very familiar to a person skilled in the
`art. The structure of the GPRS service, for example, is defined
`in ETSI specification 03.60, version 6.0.0 (Digital cellular
`telecommunications system (Phase 2+); General Packet
`Radio Service (GPRS): Service Description; Stage 2). The
`example shown in FIG. 1 illustrates the fact that the SGSN
`may communicate with the packet data network PDN via
`several gateway support nodes GGSN1, GGSN2, GGSN3.
`These gateway support nodes may also be located in different
`mobile communication networks PLMNA and PLMN B.
`One GGSN may similarly communicate with several serving
`support nodes SGSN, even though this is not illustrated in the
`figure.
`In addition to the prior art functions, the support nodes
`SGSN and GGSN of the system according to the invention are
`arranged to perform the functions to be explained in connec
`tion with FIGS. 2 to 6. They comprise processors and memory
`which can be utilized in the functions of the invention. All
`changes needed to implement the invention can be carried out
`as additional or updated software routines.
`In addition, the system may comprise means for storing
`recommendable gateway support nodes in the memory. The
`memory means are preferably located in a centralized data
`base DB. The memory means or some of them may also be
`divided between the network elements, e.g. each gateway
`support node GGSN may have a list of its own. In the latter
`case the gateway support nodes GGSN may also need addi
`tional memory. The information in the database can be
`updated e.g. via network management (not shown). For
`example, the recommended gateway support nodes can be
`stored so that each gateway support node SGSN has a list of
`its own from which a suitable support node is selected accord
`ing to the features and available resources. The way in which
`the lists are maintained or the grounds on which the selection
`is made is irrelevant to the invention. It is essential that the
`gateway support node receives, when needed, information on
`a better/more recommendable gateway support node. It may
`also receive this information directly from the operator, and
`thus the memory is not necessary.
`FIG. 2 is a flow chart illustrating the function of the gate
`way support node GGSN according to the first preferred
`embodiment of the invention in respect of one PDP context.
`In step 201 a “Create PDP Context request (or Create AA
`PDP Context request) is received from the serving support
`node. In step 202 it is checked whether the gateway support
`node supports the desired service, such as an IP-based con
`nection or a connection to a certain company network. If the
`gateway support node supports the desired service, it is
`checked in step 203 whether the gateway support node can
`provide the necessary capacity, e.g. the desired quality of
`service. If the gateway support node is capable of offering the
`necessary capacity, it is checked in step 204 whether the load
`of the gateway support node is below the limit value set by the
`operator. The operator may set a fixed limit value or change it
`according to the load. For example, when there is a lot of
`traffic in the network, the limit value may be 95% of the
`maximum load, but if the amount of traffic is small, the limit
`value may be changed to 50% of the maximum load. If the
`load is smaller than the limit value, a positive response is sent
`to the serving support node in step 205 (Create PDP Context
`Response (request accepted) or Create AA PDP Context
`Response (request accepted)). Thereafter it is checked in step
`206 whether the PDP context already exists. If there is no PDP
`context, it is created in step 207. If a PDP context exists, it is
`updated in step 208.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The invention will be described in greater detail by means
`of preferred embodiments with reference to the accompany
`ing drawings, in which
`FIG. 1 illustrates the essential parts of the logical network
`architecture of a packet radio network;
`FIG. 2 is a flow chart illustrating the function of a first
`preferred embodiment according to the invention in a serving
`Support node;
`FIG. 3 is a flow chart illustrating the function of a second
`preferred embodiment according to the invention in a serving
`support node,
`FIG. 4 is a signalling chart illustrating establishment of a
`tunnel according to the invention;
`FIGS.5 and 6 are signalling charts illustrating how one end
`of the tunnel is transferred from one gateway support node to
`another.
`
`25
`
`30
`
`35
`
`40
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`45
`
`50
`
`55
`
`The present invention is applicable to any packet-switched
`system which utilizes the tunneling technique between the
`gateway support node and the serving support node. These
`include the third-generation mobile communication systems,
`such as the Universal Mobile Telecommunications System
`(UMTS) and IMT-2000 (International Mobile Telecommuni
`cations 2000), mobile communication systems correspond
`ing to the GSM system, such as the DCS 1800 (Digital Cel
`lular System for 188 MHz) and PCS (Personal
`Communication System), and WLL systems which are based
`on the above-mentioned systems and implement a GPRS type
`packet radio. However, the invention has been described
`using the GPRS service of the GSM system as an example,
`but naturally the invention is not limited to such a system. The
`definitions of mobile communication systems change rapidly,
`which may necessitate additional changes to the invention.
`For this reason, all the terms and expressions should be inter
`preted broadly, and it should also be kept in mind that they are
`only intended to describe the invention, not to limit it.
`65
`The subnetwork BSS, networkelements SGSN and GGSN
`and external packet data network PDN shown in FIG. 1 were
`
`60
`
`Ex.1014
`APPLE INC. / Page 7 of 11
`
`

`

`5
`From steps 207 and 208 we move to step 209 where the
`situation of the gateway Support node is monitored. During
`monitoring it is checked in step 210 whether the situation is
`OK. This is found out e.g. by comparing the load and the limit
`value. The limit value can be changed even though a tunnel
`would already exist to divide the load between the gateway
`Support nodes. If the situationis OK, we continue monitoring.
`If the situation is not OK, e.g. the load situation changes and
`the operator wants to divide the load, the address of a more
`recommendable GGSN is retrieved in step 211. Thereafter in
`step 212 the serving support node is informed of the fact that
`the gateway Support node has to be changed. The information
`to be sent includes the address of the recommended gateway
`support node. In the first preferred embodiment step 212 is
`performed by sending a negative response which includes
`information on the gateway Support node recommended by
`the gateway support node (Create PDP Context Response
`(cause, GGSN2) or Create AA PDP Context Response
`(cause, GGSN2)). In other words, in the first preferred
`embodiment the GGSN may send the same message as when
`responding to the Create PDP Context request even when the
`PDP context is activated and the tunnel exists. In other
`embodiments another message may also be sent to transfer
`the end of the tunnel. Alternative messages include Delete
`PDP Context Request (GGSN2) and Reset PDP Context
`GGSN2. In the first preferred embodiment the PDP context is
`deleted in step 213 after the negative response has been sent.
`If it is noted in step 202 that the requested service is not
`supported, we move to step 214 to retrieve the address of the
`more recommendable GGSN. Then a negative response
`including information on the gateway Support node recom
`mended by the gateway support node (Create PDP Context
`Response (cause, GGSN2) or Create AA PDP Context
`Response (cause GGSN2)) is sent in step 215. Thereafter it is
`checked in step 216 whether a PDP context already exists, and
`if there is a PDP context, it is deleted in step 217. In some
`other embodiments the PDP context is not necessarily deleted
`in step 217, but the PDP context is either retained or deleted,
`depending on the case and the purpose of use. The tunnel,
`however, is removed. The same can also be done in step 213.
`If there is no capacity available, we move to step 214, from
`step 203. If the load is not below the limit value, we move to
`step 214 from step 204.
`When the load is calculated, the level of quality of service,
`i.e. QoS level, wished for the context in question can also be
`taken into account. In that case the desired QoS parameter
`values sent in the request are checked and it is evaluated
`whether the desired quality of service can be reached/guar
`anteed in step 204. If the desired quality of service cannot be
`reached or guaranteed, it is possible to indicate a GGSN
`50
`which could support the desired service better.
`Steps 203, 204 and 205 exemplify some conditions which
`the operator may define to distribute the load or to use the
`gateway Support nodes Supporting different services. The
`conditions for rejecting creation of a context may differ from
`what has been described above. The conditions may also vary
`according to the load situation or be independent of the load
`situation. Furthermore, the conditions may be defined sepa
`rately for each gateway Support node or the conditions or
`Some of them may be defined jointly e.g. in a database which
`includes the lists of the most recommendable gateway Sup
`port nodes. The condition may be gateway Support node
`specific, such as a Supported service, or common to all gate
`way Support nodes of the same operator. A common condition
`could be e.g. that the tunnel of a visiting mobile station is
`established in the home network. For example, if the mobile
`Station MS is a Subscriber of the PLMN B network in the
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`US 7,649,837 B1
`
`10
`
`15
`
`25
`
`6
`situation illustrated in FIG. 1, the condition defined for the
`GGSN1 or GGSN 2 (or for them in a database, for example)
`may be that the subscribers of the PLMN B are routed to the
`GGSN3. It is essential that at least one condition has been
`defined and the GGSN is given the address of another GGSN
`which it may include in the negative response.
`In some other preferred embodiments of the invention
`transfer of the tunnel end to another gateway Support node,
`i.e. steps 209, 210, 211, 212 and 213, can be omitted.
`FIG.3 is a flow chart illustrating the function of the serving
`support node SGSN according to the first preferred embodi
`ment of the invention in respect of one PDP context. In step
`301 a negative response to the Create PDP Context request
`is received from the serving support node (Create PDP Con
`text Response (cause) or Create AA PDP Context Response
`(cause)). In step 302 it is checked whether the corresponding
`PDP context is active. If it is, it is set to wait for a response in
`step 303 after which we move to step 304. If the PDP context
`is inactive, we move to step 304 straight from step 302. In step
`304 it is checked whether the response included the address of
`the recommended gateway support node GGSN in addition to
`the cause. If it includes the address, it is checked in step 305
`whether the same GGSN address is on the GGSN list of the
`SGSN. If it is listed, it is marked as used on the SGSN's own
`list in step 306, after which we move to step 307. By marking
`the node as used we ensure that two create requests are not
`sent to the same GGSN. If the SGSN's list does not include
`the GGSN address, we move straight to step 307 where a
`Create PDP Context request is sent to the GGSN indicated
`in the negative response. In step 308 a response is received
`from the GGSN. In step 309 it is checked whether the
`response was negative. If it was negative, we move to step 304
`to check whether the response included the GGSN address in
`addition to the cause. If the response was positive (Create
`PDP Context Request (request accepted) or Create AA PDP
`Context (request accepted)), a PDP context is activated in step
`310 and a tunnel established between the serving support
`node SGS and the gateway support node GGSN in step 311.
`If it is noted in step 304 that the negative response did not
`include the GGSN address, it is checked in step 312 whether
`there are unused GGSN addresses on the GGSN list of the
`serving Support node. If this is the case, the address on the top
`of the list is chosen in step 313 and marked as used in step 314,
`after which we move to step 307 to send a “Create PDP
`Context request. When this route is used, the create request is
`always sent to the GGSN selected from the SGSN's own list.
`If it is noted in step 312 that there are no unused GGSN
`addresses on the list of the serving Support node, a failure will
`occur (step 315) and packets cannot be transmitted.
`In some other preferred embodiments of the invention
`steps 305,306, 312,313 and 314 are not performed at all. In
`that case the gateway Support node is solely responsible for
`finding the alternative gateway Support node.
`The steps described in FIGS. 2 and 3 are not in absolute
`chronological order and some of the steps can be performed
`simultaneously or in a different order. These steps include
`steps 202,203 and 294 and steps 314 and 307. Other functions
`may also be performed between the steps, e.g. in FIG. 2 data
`of the PDP context, such as the SGSN address, may be
`updated, or the PDP context may be deleted in response to a
`delete request sent by the SGSN. It is also possible to wait for
`an acknowledgement from the serving Support node between
`steps 212 and 213 of FIG. 2 and delete the PDP context only
`in response to an acknowledgement which indicates that
`another tunnel has been established successfully. In the
`embodiments of the invention where the negative response is
`used only when the tunnel is established, another message,
`
`Ex.1014
`APPLE INC. / Page 8 of 11
`
`

`

`US 7,649,837 B1
`
`5
`
`7
`e.g. delete or reset, is sent in step 212. In that case at least steps
`302 and 303 are omitted from the example of FIG.3 when the
`negative response is received. When another message is
`received, these steps are performed.
`FIGS. 4,5 and 6 illustrate examples of signalling according
`to the invention in different embodiments. Signalling is based
`on ETSI recommendation GSM 09.60 version 6.2.0, which is
`incorporated herein by reference.
`FIG. 4 illustrates signalling related to PDP context activa
`tion. In the example of FIG. 4 the mobile station MS sends an
`Activate PDP Context request to the serving support node
`SGSN in message 4-1. Having received the message the
`serving support node SGSN and the mobile station MS carry
`out security functions in message 4-2. After the security func
`tions have been performed, the serving support node SGSN
`15
`sends a Create PDP Context request to the gateway support
`node GGSN1 in message 4-3. Messages 4-1, 4-2 and 4-3 are
`in accordance with the prior art. Having received message 4-3
`the gateway support node GGSN1 checks in step 4-4 whether
`the conditions (or condition) for acceptance are fulfilled. If
`necessary, the limit value related to the condition or the con
`dition is retrieved from a database. This is not, however,
`shown in FIG. 4. Examples of the conditions are given in
`connection with FIG. 2. In the example of FIG. 4 it is assumed
`that the GGSN1 cannot accept the PDP context request. Thus
`it requests the address of a more suitable GGSN from the
`database DB in message 4-5. The message may contain infor
`mation on the condition which caused rejection and the cause
`of rejection. The message may also contain all parameters and
`attributes transmitted in message 4-3. The database retrieves
`the address GGSN2 on the basis of the information given in
`message 4-5 and sends it back in message 4-6. Messages 4-5
`and 4-6 are not actual signalling messages. Messages 4-5 and
`4-6 are used for indicating the database search performed in
`this step. Having received message 4-6 the gateway Support
`node GGSN1 sends a “Create PDP Context response the
`cause parameter of which differs from the request accepted
`value to the serving support node SGSN in message 4-7. The
`message also contains the address of the GGSN2. The serving
`support node SGSN separates the address from message 4-7
`in step 4-8 and sends a Create PDP Context request to the
`gateway support node GGSN2 in message 4-9. Message 4-9
`is in accordance with the prior art. Having received message
`4-9 the gateway support node GGSN2 checks in step 4-10
`whether the conditions (or condition) for acceptance are full
`filled. In this case the conditions (or condition) are fulfilled
`and the gateway support node GGSN2 sends a Create PDP
`Context response the cause parameter of which is request
`accepted to the serving support node SGSN in message 4-11.
`In other words, message 4-11 is a positive response. The
`serving support node SGSN transmits the acceptance to the
`mobile station MS according to the prior art by sending an
`Active PDP Context accept in message 4-12. After this the
`PDP context is activated from the mobile station, which can
`send and receive packets.
`The PDP context activation illustrated in FIG. 4 can be
`performed when the mobile station attaches to the GPRS
`network. Alternatively, the user may activate the context or
`activation may be performed in response to a PDP context
`activation request received from the GPRS network.
`FIG. 5 is a signalling chart illustrating a situation in which
`a tunnel has been established between the SGSN and the
`GGSN2. In other words, the PDP contexts are active. In step
`5-1 the operating conditions of the gateway Support node
`change. For example, the operator drives the gateway Support
`node down or the load of the gateway Support node exceeds
`the limit value because the limit value has been changed.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`8
`Change of the operating conditions may also be an update of
`the PDP context received from the serving support node e.g.
`as the desired quality of service or the serving Support node
`changes. Thus one end of the tunnel is to be transferred from
`the GGSN2 to another gateway support node. As a result of
`this, the gateway Support node sends message 5-2 to the
`serving support node SGSN. Depending on the embodiment,
`the message may be a Create PDP Context response the
`cause parameter value of which differs from the request
`accepted value, a Delete PDP Context or a Resent PDP
`Context. Regardless of the type of the message it always
`contains the address of a new, more Suitable gateway Support
`node GGSN3 which is either obtained from the operator or
`retrieved from the database. Having sent the message the
`GGSN2 deletes the PDP context in step 5-3, i.e. removes the
`tunnel. Having received message 5-2 the serving Support
`SGSN removes the tunnel to the GGSN2 in step 5-4, separates
`the address from message 5-2 and sends a Create PDP Con
`text request to the gateway Support node GGSN3 in message
`5-5. Having received message 5-5 the gateway support node
`GGSN3 checks in step 5-6 whether the conditions (or condi
`tion) for acceptance are fulfilled. This time the conditions (or
`condition) are fulfilled and the gateway support node GGSN3
`sends a Create PDP Context response the cause parameter of
`which is request accepted to the serving support node SGSN
`in message 5-7. Thereafter the SGSN establishes a new tunnel
`and continues transmission of packets using this new tunnel.
`The mobile station does not need to be informed of the new
`tunnel.
`If the conditions are not fulfilled in step 5-6, the gateway
`Support node proposes another gateway Support node.