as United States
`a2) Patent Application Publication co) Pub. No.: US 2002/0181468 A1
`
` Lucidarmeetal. (43) Pub. Date: Dec. 5, 2002
`
`
`US 20020181468A1
`
`(54) METHOD OF TRANSMITTING IP PACKETS
`VIA A CELLULAR RADIO
`COMMUNICATION SYSTEM, AND THE
`CELLULAR SYSTEM EQUIPMENT FOR
`IMPLEMENTING THIS METHOD
`
`(76)
`
`Inventors: Thierry Lucidarme, Montigny Te
`Bretonneux (FR); Pierre Lescuyer,
`Montigny Le Bretonneux (FR)
`Correspondence Address:
`Michael L. Kenaga
`PIPER RUDNICK
`P.O. Box 64807
`Chicago, IL 60664-0807 (US)
`
`(21) Appl. No.:
`
`10/161,363
`
`(22)
`
`Filed:
`
`Jun. 3, 2002
`
`(30)
`
`Foreign Application Priority Data
`
`Jun. 1, 2001
`
`(FR) woe ceceeeeeeeseeeseeeeneee FR 01 07254
`
`Publication Classification
`
`(SD) Tite C17 oe ceecsesnneseesececneeeneenneeeess HO4L 12/56
`(52) US. Ch oe 370/395.2; 370/338; 370/328;
`370/401
`
`ABSTRACT
`(57)
`The invention concerns the dynamicreservation of resources
`according to the RSVP protocol for transmitting an appli-
`cation flow in the form offirst packets between a radio
`terminal and a remote unit interconnected via a first IP
`network and a cellular radio communication system. The
`cellular radio communication system uses a second IP
`network, or even a third IP network, in its core network.
`According to the invention,
`the dynamic reservation of
`resources in the first IP network is completed by a second
`dynamic reservation of resources in the second IP network,
`and where necessary a
`third dynamic reservation of
`resources in the third IP network. For this,
`transmission
`elements of the cellular radio communication system per-
`form the association between the tunnel identity used for
`transmitting the first packets of the application flow and the
`parameters assigned to each RSVPsession.
`
`
`
`1
`
`APPLE 1026
`
`APPLE 1026
`
`1
`
`

`

`Patent Application Publication
`
`Dec. 5,2002 Sheet 1 of 7
`
`US 2002/0181468 Al
`
`
`
`2
`
`

`

`Patent Application Publication
`
`Dec. 5,2002 Sheet 2 of 7
`
`US 2002/0181468 Al
`
`TCP/UDP IP L2 Lt
`
`APPLICATION
`REMOTEUNIT 11
`ROUTERIP (12)
`P|Le Uf
`\
`
`I|I
`
`10
`
`|t~i‘C™SCCS
`
`SGSNGn 30
`UDP209|IP|pe U1
`FIG.2
`fF|| Ee—|MAC|ORKERF|Ltbis| BSSG 24/25
`
`22
`
`Um
`
`||||a
`S/o
`a
`a /2
`OS
`Ole
`QO
`a)
`=
`m|O
`wn
`<i
`
`Le
`Ly
`{e) a,
`fof o 19
`Pra)
`a; 2/s
`=laon
`x
`= wf
`ol =
`
`3
`
`

`

`Patent Application Publication
`
`Dec. 5,2002 Sheet 3 of 7
`
`US 2002/0181468 Al
`
`APPLICATION
`
`TCP/UDP a Li
`|p L2 Lt
`
`REMOTEUNIT nN
`ROUTERIP (12)
`
`IP N
`wed
`
`FIG.3.
`
`= O
`
`”
`
`R
`
`lu
`
`3
`
`Bla21D
`3S} 0
`2
`alo
`oT
`
`gS
`co
`
`oO
`
`<
`=
`
`ela|tsi—‘Cs—sSOY7[IPaGIP||QWUDP Lpaa||feGnGGSN 32
`
`oO
`OI
`
`a
`~
`
`Ww
`a
`<q
`<i
`
`|am
`
`IP AALS|OranFe]Libis RNS c7
`[sie|UOP
`
`MAC
`RLC
`
`Ls >
`uea] w
`=} aM
`Clow
`5] =
`
`4
`
`

`

`Patent Application Publication
`
`Dec. 5, 2002
`
`Sheet 4 of 7
`
`c0l
`
`c0¢
`
`MO14NO}
`
` 3LVOMddV001dI
`
`H1Vd‘002di
`
`\eceaeeerensatenennveesnnesnnanerrnstd_AS3Y*002ed]
`
`
`
`AS34Y‘001dI
`
`H1Vd*OOdI 0O¢
`
`US 2002/0181468 Al
`
`
`LINN(cl)oeO¢C2C2
`
`3l0w34dIH3LNOYNS99NS9S9S8TWNIWULJTIGOW
`
`iL
`
`7Ol4
`
`
`
`
`
`5
`
`
`
`
`
`

`

`Patent Application Publication
`
`Dec. 5, 2002
`
`Sheet 5 of 7
`
`US 2002/0181468 Al
`
`0G
`
`
`
`AS3Y‘001di]
`
`
`aLOWSYdI43..N04NS99NS9Sos@if
`
`
`FUGOW
`LINN(cl)ofO¢C2
`,CoOl4
`
`
`
`H1Vd*001dI
`
`TWNINYSL
`
`6
`
`

`

`SLOW3Y (cl)
`
`
`
`ocISNS99NSOS
`
`9Ol|4
`
`ONY
`
`Lo
`
`zc
`
`aan‘002dIscr,O02di
`AS3q|AS83800dT
`
`TWNINYSLTOW
`
`Sheet 6 of 7
`
`US 2002/0181468 Al
`
`LINN
`
`LL
`
`dI431N0u
`
`Patent Application Publication
`
`Dec. 5, 2002
`
`AS3d:
`
`
`
`H1Vd‘002di
`
`
`
`ASSAY‘002di
`
` H1Vd*001d]
`
`O¢
`
`oo
`
`7
`
`
`

`

`Patent Application Publication
`
`Dec. 5, 2002
`
`Sheet 7 of 7
`
`US 2002/0181468 Al
`
`cO¢
`
`cOG
`
`cOl
`
`AS3u'001dl
`
`JLOWSY
`
`LIND
`
`LL
`
`dI43in0u (dl)
`
` AS34‘O0ldl Oc
`
`AS3Y‘00dI
`
`QT3LUD19
`
`$02
`
`H1Vd?O02dI
`
`ASSu:002dl.
`g02CISL*dyNVY
`
`ASSAY;00edi
`
`
`
`H1Vd:002di
`
`F0lQedNOLVOMdd:OOLAI
`
`4914
`
`
`
`
`
`
`
`ceIS/2$2NS99NS9SONYWNIWYALJIIGON
`
`8
`
`
`
`
`

`

`US 2002/0181468 Al
`
`Dec. 5, 2002
`
`METHOD OF TRANSMITTING IP PACKETS VIAA
`CELLULAR RADIO COMMUNICATION SYSTEM,
`AND THE CELLULAR SYSTEM EQUIPMENT FOR
`IMPLEMENTING THIS METHOD
`
`BACKGROUND OF THE INVENTION
`
`[0001] The present invention relates to signalling tech-
`niques aimedat achieving a certain Quality of Service (QoS)
`for packet transmission networks such as the Internet. In
`particular, the invention relates to networks operating under
`the IP protocol (Internet Protocol, see Request for Com-
`ments (RFC) 791 published in September 1981 by the
`Internet Engineering Task Force (ETF)).
`
`It is knownthat IP networks transport data in the
`[0002]
`form of packets or datagrams under a mechanism knownas
`“best effort”.
`
`[0003] Several enhancements have been proposed for the
`IP protocol in the network layer of the OSI model, for
`providing much greater quality of service in certain infor-
`mation flows.
`
`[0004] Some of these techniques (“Diffserv”, see RFC
`2474 and 2475 published in December 1998 by the IETF)
`use special marking of packets at the network boundary,
`chiefly with the aid of the TOS (Type of Service) field in the
`IP header. The network’s internal routers do not differentiate
`the flows in terms of quality of service, but only the classes
`of packets specified by the markings.
`
`(0005] The invention rather relates to techniques (“Int-
`serv”, see RFC 1633 published in June 1994 by the IETT)
`that reserve resources in the routers based on the flows
`processed, which can be identified by the source and desti-
`nation IP addresses, and the port numbers of the transport
`protocol layer. The invention is aimed more specifically at
`those of
`these
`techniques
`that dynamically reserve
`resources. The most commonofthese is the RSVP protocol
`(“Resource reSerVation Protocol”, see RFC 2205 published
`in September 1997 by the IETF).
`
`[0006] The resources undergoing such dynamic reserva-
`tion depend on the specific implementations of the protocol.
`They may correspond, for example, to portions of band-
`width, or to portions of packet buffer memories.
`
`[0007] Reserving such resources requires signalling pro-
`cedures to establish and maintain states in the routers
`
`encountered along the packet path in the network. These
`procedures entail transmitting special datagrams along the
`path. Packet routing then takes place taking into account the
`states thus established and maintained.
`
`[0008] RFC 2746, “RSVP Operation over IP Tunnels”,
`published in January 2000 by the IETF describes how to
`implement RSVPin IP tunnels carrying IPtraffic (see also
`EP-A-1 035 688). This IP traffic is in the form of datagrams
`of an innerIP layer, or IP application layer. The “tunnel”is
`formed between two routers of this outer layer, where these
`datagrams are encapsulated in the datagrams of an outer IP
`layer, or IP transport layer, linking up these tworouters (this
`outer layer is viewed as belonging to level 2 of the OSI
`model fromthe inner layer). The above documents describe
`how to associate RSVP sessions of the inner layer with
`RSVPsessionsofthe outer layer in response to the detection
`of outer layer signalling datagramsbythe tunnel end routers.
`
`[0009] The RFC 2746 mechanism is based on an obser-
`vation of the datagrams of the inner layer at the two ends of
`the tunnel and on specific information exchanges between
`the routers located at these endpoints. It is not applicable
`when one of the tunnel endsis not capable of analysing the
`IP datagram headers of the inner layer.
`
`there are network architectures that use IP
`‘Yet
`[0010]
`tunnels for carrying IP traffic without the ends of these
`tunnels having the ability to analyse IP traffic as a matter of
`course. The aforementioned mechanism then proves defi-
`cient.
`
`[0011] This situation is encountered especially in cellular
`radio communication networks enabling wireless access to
`packet networks, especially of the IP type (Intranet or
`Internet). Some second generation cellular networks (GSM,
`Global System for Mobile communications) nowinclude a
`packet transmission service called GPRS (General Packet
`Radio Service). The third generation cellular systems, espe-
`cially UMTS (Universal Mobile Telecommunications Sys-
`tem), are designed with multimedia in mind, and therefore
`incorporate such packet transmission services.
`
`[0012] These cellular systems include a core network
`performing communication and user managementfunctions,
`and one or more radio access networks that supply the links
`between the infrastructure and the radio terminals.
`
`In the aforementioned systems (GPRS, UMTS),
`[0013]
`the core network is based on IP technology. Accordingly,
`when a terminal exchangesdata in the form of IP datagrams,
`these data undergo double IP encapsulation in the core
`network. An inner IP layer links the radio terminal with the
`packet network(Internet or Intranet). Acore network switch,
`called a GGSN (Gateway GPRS Support Node) forms the
`packet network edge router with which the terminal
`exchanges its IP datagrams in a single hop of the inner IP
`layer. In the core network, these IP datagrams are incorpo-
`rated into data units of a GIP tunnelling protocol (GPRS
`Tunnelling Protocol, see technical specification 3GPP TS
`29.060, version 3.8.0 published in March 2001 bythe 3GPP
`(3"* Generation Partnership Project), themselves encapsu-
`lated in datagrams of an outer IP layer linking the GGSN
`with the terminal serving switch called an SGSN (Serving
`GPRSSupport Node).
`[0014] The IP/GTP/IP tunnel extends from the GGSN to
`the SGSN. One ofits ends (the SGSN) does not have the
`functionalities of an inner JP layer router. In particular, it
`does not have the ability of the GGSN to analyse the header
`and possibly a part of the data of the inner
`IP layer
`datagrams.
`(0015]
`In a typical scenario, an “Intserv” service such as
`RSVPis provided between one terminal and another termi-
`nal or remote server connected to the packet network
`(internet or Intranet).
`‘The signalling datagrams are thus
`processed by the routers of the inner IP layer, which can
`reserve the required resources if they are available. A weak
`link in this chain may be the outer IP layer between the
`GGSNand the SGSN, which generally applies to a “best-
`effort” mechanism.
`In fact, a mesh network may cxist
`between the GGSN and the SGSN comprising a large
`numberof routers.
`
`[0016] As the SGSN does not have this functionality of
`analysing the IP datagram headers of the innerIP layer, the
`RFC 2746 mechanism is not applicable in the tunnel.
`
`9
`
`

`

`US 2002/0181468 Al
`
`Dec. 5, 2002
`
`[0017] Giving SGSNsanability to analyse the data fields
`(payload) of the outer IP layer datagrams for the sole
`purpose of detecting possible RSVPsignalling packets from
`the inner IP layer would be a very complex and costly
`solution, noting that these RSVP packets represent only a
`very small fraction of the total traffic.
`
`the RSVP signalling relay mecha-
`[0018] Accordingly,
`nism suggested in RFC 2746 and EP-A-1 035 688 cannot be
`applied to cellular networks. Thus, the traffic in the core
`network, including the traffic that mostly makes do with
`“best-effort” service, may hinder supplying the quality of
`service required for an RSVP flow. This reduces the ability
`of the cellular operator to offer its customers dynamically
`reserved “Intserv” services.
`
`In “Supporting IP QoS in the General Packet Radio
`[0019]
`Service”, (IEEE Network, September/October 2000, pp.
`8-17), G. Priggouris et al. describe an adaptation of a GPRS
`network for providing Diffserv and Intserv type services.
`According to this article, the GGSN respondsto the receiv-
`ing of a PATH packet of the RSVP protocol in the inner IP
`layer by sending to the SGSN an initialization message of
`another RSVP session in the outer layer. Such operation
`requires a non-standard implementation of RSVP in the
`outer layer, which complicates the design of the SGSN
`especially. Moreoverit leads to, in an under-optimum way,
`triggering steps for establishing a tunnel as the reservation
`may fail in the outer layer.
`
`SUMMARY OF THE INVENTION
`
`[0020] One aim of the present invention is to propose a
`mechanism for simple an efficient implementation, allowing
`a cellular operator to offer RSVP services to his clients.
`
`[0021] The present invention concerns a methodoftrans-
`mitting packets along a first IP network via a cellular radio
`communication system having equipment
`interconnected
`through the intermediary of a second IP network. This
`equipment comprises at least a gateway router havinga first
`interface for exchanging first packets along the first IP
`network and a second interface for exchanging second
`packets along the second IP network. This equipment also
`comprises at least a switching node havinga first interface
`with a radio access network making links with radio termi-
`nals and a second interface for exchanging second packets
`along the second IP network. At least some of the radio
`terminals include means of communication alongthe first IP
`network via the cellular system, the gateway router consti-
`tuting, in the first IP network, an edge router that exchanges
`the first packets with said terminals in a single hopofthefirst
`IP network. Each of these first exchanged packets is encap-
`sulated in at least one data unit of a tunnel protocol imple-
`mented between the second interfaces of a gateway router
`and a switching node, said data unit
`including a tunnel
`identity and itself being encapsulated in at least one second
`packet. The transmission method comprises the following
`steps:
`
`detecting first signalling packets carrying
`{0022]
`RESV messages of the RSVP protocol concerning a
`first session of the RSVP protocol in the first IP
`network relative to an application flow offirst pack-
`ets between a radio terminal and a remote unit
`connected to the first IP network;
`
`in responseto the detectionofat least some of
`[0023]
`the first signalling packets, associating a second
`session of the RSVP protocol
`in the second IP
`network with a tunnel identity included in the data
`units in which the first packets of the application
`flow are encapsulated, said second session being
`relative to a flow of second packets in which said
`data units are encapsulated between a gateway router
`and a switching node; and
`
`transmitting second signalling packets in the
`[0024]
`second JP network for establishing and/or updating
`the parameters of the second session associated with
`said tunnel identity.
`
`In order to achieve consistent resource reservation
`[0025]
`between the two IP networks, the second RSVPsession used
`in the second IP network is advantageously determined
`according to the characteristics of the first RSVP session
`used in the first IP network. To do this, the association of the
`second RSVP session with said tunnel
`identity includes
`assigning quality-of-service parameters to the second RSVP
`session selected according to quality-of-service parameters
`assigned to the first session and obtained from the first
`signalling packets detected.
`
`[0026] According to the known method ofoperation of the
`RSVPprotocol, a session of this protocol is initialized in the
`first IP network by a signalling packet forming a PATH
`message transmitted by the source of the application flow to
`the remote destination unit. In response, this remote unit
`sends backto the source a signalling packet forming a RESV
`message. This RESV message notifies the availability of
`sufficient resources in each of the transmission elements
`
`located on the path between the destination unit and the
`router that processes it with respect to the quality of service
`requested by the PATH message. It is propagated up to the
`source, which beginsto transmit the flow packets if adequate
`resources have been able to be reserved all along the path.
`
`[0027] The step of detecting the first signalling packets is
`preferably performed at the first interface of the gateway
`router.
`
`[0028] The application flow of first packets may be a
`downlink flow, from the remote unit connected tothefirst IP
`network to a radio terminal, or an uplink flow, from a radio
`terminal to the remote unit connected to the first IP network.
`
`in
`In the case of a downlink application flow,
`[0029]
`responseto the detection of the RESV message, the gateway
`router associates the second RSVP session with the tunnel
`
`identity included in the data units in which the first packets
`of the application flow are encapsulated. The gateway router
`then sends a signalling packet carrying an RSVP protocol
`PATH message on the second IP network, to the switching
`node. Dynamic resource reservation is then performed
`between the gateway router and the switching node in the
`second IP network, separately from the first IP network,
`following the RSVP protocol standard procedure.
`
`the
`In the case of an uplink application flow,
`[0030]
`transmission of the RSVP protocol PATH message in the
`second IP networkis carried out by the switching node in the
`direction of the gateway router. For this, in response to the
`detection of at least someofthefirst signalling packetsat the
`first gateway router interface, this gateway routerfirst trans-
`mits a control message to the switching node, via the second
`
`10
`
`10
`
`

`

`US 2002/0181468 Al
`
`Dec. 5, 2002
`
`IP network. This control message belongs to a control plane
`of the tunnel protocol and designates the tunnel identity
`included in the data units in which the first packets of the
`application flow are encapsulated. This control message also
`containsat least someof the quality-of-service parameters of
`the first RSVP session.
`
`included in the data units in which the first packets of the
`application floware encapsulated. This second control mes-
`sage reproducesat least a part of the data contained in the
`first control message. Furthermore, it falls under a specific
`communications protocol between the switching node and
`the control unit.
`
`In response to the detection of this control mes-
`[0031]
`sage, the switching node then associates the second RSVP
`session internal to the second IP network with the tunnel
`identity designated in this control message. It then sends to
`the gateway router, on the second IP network, a signalling
`packet carrying a PATH message corresponding to this
`second RSVPprotocol session. Dynamic IP resource reser-
`vation is then performed between the switching node and the
`gatewayrouter in the second IP network,separately from the
`first IP network, following the RSVP protocol standard
`procedure.
`
`[0032] Thus, according to the invention, in both cases of
`an application flow, downlink and uplink,
`reserving
`resources in the first IP network gives rise to reserving
`resources in the second IP network. If this reservation fails,
`the transmission along the second IP network may be in
`“best-effort” mode. A homogeneous, global resource reser-
`vation session is accordingly set up on both IP networks.
`
`In somecellular systems, other transmission ele-
`[0033]
`ments of the radio access network are also connected to the
`preceding switching nodes via another IP network. These
`other transmission elements are chiefly control units pro-
`vided with network interfaces communicating with the first
`access interface of at least one switching node through the
`intermediary of a third IP network. At least one part of the
`existing tunnel protocol between the gatewayrouter and the
`switching node is implemented between the network inter-
`faces of said control units and the first access interface of the
`switching node.
`
`transmission method
`the packet
`In preference,
`[0034]
`according to the invention then includes, in response to the
`association with a tunnel identity of a second RSVPsession
`relative to a flow of second packets in which data units of the
`tunnel protocol are encapsulated between a gateway router
`and a switching oode,
`the association with said tunnel
`identity of a third RSVPsession in the third IP network,for
`transporting between the switching node and a radio access
`network control unit, IP packets in whichsaid data units are
`encapsulated.
`
`the switching
`[0035] For a downlink application flow,
`node associates a third RSVP session with said tunnel
`
`identity. Third signalling packets are then exchanged in the
`third IP network to set up and/or update parameters of this
`third RSVP session. The switching node then sends a PATH
`message corresponding to this third RSVP session, on the
`third IP network. Dynamic IP resource reservation is then
`performed between the control unit and the switching node
`in the third network, separately from the first and second
`networks, according to the RSVP standard procedure.
`
`(0036] For an uplink application flow, the association of a
`third RSVPsession with said tunnel identity is performed by
`the control unit. For this, in response to the switching node
`receiving the first control message sent by the gateway
`router, the switching node transmits a second control mes-
`sage to the control unit, designating the tunnel
`identity
`
`[0037] The third RSVPsession in the third IP network is
`then initialized by the control unit by sending a PATH
`message to the switching node.
`
`[0038] Another aspect of the present invention relates to a
`cellular radio communication system including network
`equipment set up to use a method as defined above, as well
`as some of this equipment.
`
`[0039] The invention is thus aimed at a gateway router
`having a first interface for exchangingfirst packets along a
`first IP network and a second interface for exchanging
`second packets along a second IP network, and forming an
`edge router of the first IP network, set up to exchangefirst
`packets with radio terminals in a single hop of the first IP
`network. Each of these first exchanged packets is encapsu-
`lated in at least one data unit of a tunnel protocol imple-
`mented between said secondinterface and a switching node,
`said data unit including a tunnel identity and itself being
`encapsulated in at least one second packet exchanged along
`the second IP network. This gateway router according to the
`invention comprises:
`
`[0040] means for detecting on thefirst interfacefirst
`signalling packets carrying RESV messages of the
`RSVP protocol concerning a first session of the
`RSVPprotocol in the first IP network relative to an
`application flow of first packets between a radio
`terminal and a remote unit connected to the first IP
`network;
`
`in response to the
`[0041] means for associating,
`detection of at
`least some of the first signalling
`packets, a second RSVP session in the second IP
`network with a tunnel identity included in the data
`units in which the first packets of the application
`flow are encapsulated, said second RSVPsession
`being relative to a flow of second packets in which
`said data units are encapsulated between said second
`interface and a switching node;
`
`transmitting second signalling
`for
`[0042] means
`packets in the second IP network for establishing
`and/or updating parameters of the second RSVP
`session associated with said tunnel identity.
`
`[0043] According to another aspect, the invention con-
`cerns a cellular radio communication system core network
`switching node, comprising a first interface with a radio
`access network providing links with radio terminals and a
`second interface for exchanging packets along an IP network
`with at least a gateway router, said packets carrying data
`units of a tunnel protocol supported by the secondinterface,
`each data unit including a tunnel identity and data forming
`either a control message if the data unil belongs to a control
`plane of the tunnel protocol, or user data if the data unit
`belongsto a user plane of the tunnel protocol. This switching
`node also includes means for associating,
`in response to
`receiving from a gateway router a tunnel protocol special
`data unit belonging to the control plane, an RSVPsession in
`said IP network with a tunnel identity designated in the
`
`11
`
`11
`
`

`

`US 2002/0181468 Al
`
`Dec. 5, 2002
`
`control message of said special data unit and transmitting to
`said gateway router at least one signalling packet in the IP
`network for setting and/or updating parameters of the RSVP
`session associated with the tunnel identity designated in the
`control message, said RSVP session being relative to a
`packet flow in which tunnel protocol data units are encap-
`sulated that belong to the user plane and contain the tunnel
`identity designated in the control message.
`
`[0044] The first interface of the switching node to which
`the invention applies also supports the IP protocol, as well
`as the user plane of the tunnel protocol for communicating
`with control units of the radio access network. According to
`the invention, the switching node further includes meansfor
`associating,
`in response to the association with a tunnel
`identity of an RSVP session relative to a flow of packets in
`which data units of the tunnel protocol belonging to the user
`plane and containing a tunnel
`identity are encapsulated
`between the switching node and a gateway router, another
`RSVPsession with the tunnel
`identity, for transporting
`between the switching node and a radio access network
`control unit, IP packets in which the data units are encap-
`sulated.
`
`the invention proposes a cellular radio
`[0045] Finally,
`communication system radio network controller, comprising
`a first communications interface with radio terminals and a
`secondinterface for exchanging packets along an IP network
`with at least a switching node, said packets carrying user
`data units of a tunnel protocol supported by the second
`interface, each user data unit including a tunnel identity. This
`radio network controller further includes means for associ-
`ating,
`in response to receiving a control message from a
`switching node designating a tunnel
`identity, an RSVP
`session in said IP network with the tunnel identity desig-
`nated in the control message and transmitting to said switch-
`ing node at least one signalling packet in the IP network for
`setting and/or updating parameters of the RSVP session
`associated with the tunnel identity designated in the control]
`message, said RSVPsession being relative to a packet flow
`in which are encapsulated data units of the tunncl protocol
`containing the tunnel
`identity designated in the control
`message.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0046] FIG. 1 is a general diagram of a communications
`system architecture to which the invention can be applied;
`
`[0047] FIGS. 2 and 3 are diagrams illustrating commu-
`nications protocol stacks used in system entities of FIG. 1,
`in the case of second and third generation cellular systems
`respectively;
`
`[0048] FIG. 4 is a diagram illustrating various messages
`exchanged for handling a downward RSVPflow in a method
`according to the invention implemented in a second genera-
`tion cellular network connected to an IP network;
`
`[0049] FIG. 5 is a diagram similar to that in FIG.4 in the
`case of an upward RSVPflow;
`
`[0050] FIGS. 6 and 7 are diagramsrespectively similar to
`those in FIGS. 4 and 5 in an implementation of the method
`according to the invention in a third generation cellular
`network connected to an IP network.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`[0051] The communications system shown diagrammati-
`cally in FIG. 1 comprises a fixed part 10 and a cellular
`communications system 20. The fixed part 10 comprises an
`IP network 12, the Internet or an Intranet for example. This
`network 12 operates standardly according to the IP protocol
`(see RFC 791 of the JETF for version 4, and RFC 2460 of
`the IETF for version 6). Remote units 11 (IP servers or
`terminals) are connected to the IP network 12.
`
`[0052] The cellular radio communication system 20 is
`standardly divided into a core network 21, comprising
`interconnected packet switches, and an access network 22
`providingthe radio links with the mobile radio terminals 23.
`
`In the example shown,the cellular radio commu-
`[0053]
`nication system 20 combines second generation elements
`(GSM)andthird generation elements (UMTS). In GSM,the
`access network 22, called a BSS (Base Station Subsystem),
`is composedof base stations (BTS) 24 distributed over the
`coverage area for communicating by radio with mobile
`terminals 23, and base station controllers (BSC) 25 con-
`nected to the core network 21. In the case of UMTS,the
`access network 22, called an RNS (Radio Network System),
`is composed of base stations (BTS) 26 and radio network
`control (RNC) units 27 connected to the core network 21.
`
`[0054] The core network 21 switching nodes are called
`GSN (GPRS Support Node). The switching nodes 30, 31
`connected to the access network 22 are called SGSN (Serv-
`ing GSN)and act as the mobile terminal 23 serving switch.
`Other switching nodes 32 of the core network 21, called
`GGSN (Gateway GSN), are gateway routers connected to
`the IP network 12. These GGSN 32 are connected to the
`SGSN30, 31 to enable the mobile terminals 23 to access the
`IP network 12. FIG. 1 shows several GGSN 32, which may
`correspond to gateway routers run by different suppliers
`called ISPs (Internet Service Providers).
`
`[0055] FIGS. 2 and 3 are illustrations of the protocols
`capable of being implemented in packet mode communica-
`tions between a mobile terminal 23 and a remote unit 11.
`This remote unit 11 is accessible via one or more IP routers
`belonging to the IP network 12. In both cases, the protocols
`used are the samein the fixed part 10 and at the interface Gn
`between the GGSN 32 and the SGSNs 30, 31. In the IP
`network 12, above layers 1 and 2 of the OSI model (L1, L2),
`IP is used as the network protocol. The same IP layer 100 is
`present in the mobile terminals 23 when they access the IP
`network 12. This access may take place during TCP (Trans-
`mission Control Protocol , RFC 793 of the IETF) sessions,
`or by UDP (User Datagram Protocol, RFC 768 of the IETF)
`datagram exchange,to enable applications run in the mobile
`23 and the remote unit 11 to exchange data grouped into
`flows, called application flows.
`
`[0056] The protocols used in the radio communication
`system 20 are described, for the second generation (FIG.2),
`in GSM Recommendations 03.60, 03.64, 08.16 and 09.16
`published by the ETSI (European Telecommunications Stan-
`dards Institute), and for the third generation (FIG. 3) in
`specifications 3G TS 25.301 and 3G TS 25.410 published by
`the 3GPP.
`
`12
`
`12
`
`

`

`US 2002/0181468 Al
`
`Dec. 5, 2002
`
`[0057] At the “Gn”interface, additional IP 200 and UDP
`layers, as well as a GTP protocollayer, are present between
`layer 2 and the IP layer 100 corresponding to that of the
`mobile terminal 23.
`
`In the third generation UMTSnetwork, additional
`[0058]
`IP 200'", UDP and GTP layers are also present at the “lu”
`interface between the SGSN 31 and the RNC 27. The IP
`
`network on whichthe IP layer 200'is deployed for exchanges
`between the RNC and the SGSN is based on a link-layer
`adaptation protocol AAL 5. It can be the same IP network as
`that serving the SGSN/GGSN exchanges, or a different
`network. In the case of GPRS (FIG. 2),
`the SGSN 30
`communicates under other protocols with the BSC 25 and
`the mobile terminal 23.
`
`[0059] The GGSN 32 located at the interface between the
`cellular core network 21 and the IP network 12 therefore
`includes an IP layer 100 router commonto the IP network 12
`and the mobile terminal 23. Transmission between a GGSN
`and a mobile terminal is performed alongthis inner IP layer
`100 in a single hop, the GGSN forming an edge router. As
`for the SGSNs30, 31, they do not possess this IP layer 100,
`and consequently do not have access to the packets trans-
`mitted between the remote unit 11 and the mobile terminal
`
`23, along the IP network 12 via the GGSN 32. Onthe other
`hand, the SGSNs30, 31 share the second IP layer 200 with
`the GGSNs32, as well as the GTP and UDPprotocollayers.
`
`It is assumedhere that the IP network 12 and the
`[0060]
`core network support IP network are both equipped to
`implement the RSVPprotocol.
`
`and5, reference 102 designates the messages exchanged for
`establishing or maintaining these RSVPsessionsat the level
`of the IP layer 100.
`
`[0066] The PATH message, in addition to the IP address
`and the UDP port number of the application flow source
`(FilterSpec), contains data (FlowSpec) describing the qual-
`ity of service required for the application flow.
`
`In response to this PATH message, the recipient of
`[0067]
`the application flow sends back an IP layer 100 RESV
`message to the source. This RESV messageis relayed by all
`the transmission elements from the destination to the source,
`and indicates the availability of sufficient resources in each
`of these elements with respect to the PATH message request,
`by confirming that these resources have been duly reserved.
`The GGSN32 also makes the required reservations whenit
`receives this RESV messageat its interface with the inner IP
`layer 100.
`
`In response to the detection by the GGSNof these
`[0068]
`messages 102, and in particular the RESV message, actions
`are carried out within the frameworkof an outerIP layer 200
`RSVPsession between the GGSN and the SGSN.In FIGS.
`4 and5, reference 202 designates the messages exchanged
`for establishing or maintaining these RSVPsessions at the
`level of the IP layer 200. When the PATH/RESV exchange
`detected in the in