WO2003105505A1 - Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles - Google Patents

Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles Download PDF

Info

Publication number
WO2003105505A1
WO2003105505A1 PCT/FR2003/001738 FR0301738W WO03105505A1 WO 2003105505 A1 WO2003105505 A1 WO 2003105505A1 FR 0301738 W FR0301738 W FR 0301738W WO 03105505 A1 WO03105505 A1 WO 03105505A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
packet
real
mobile station
mode
Prior art date
Application number
PCT/FR2003/001738
Other languages
English (en)
Inventor
Vincent Muniere
Original Assignee
Evolium S.A.S.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Evolium S.A.S. filed Critical Evolium S.A.S.
Priority to EP03757136A priority Critical patent/EP1516500A1/fr
Priority to US10/517,370 priority patent/US20050169207A1/en
Publication of WO2003105505A1 publication Critical patent/WO2003105505A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/22—Manipulation of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/14—Interfaces between hierarchically different network devices between access point controllers and backbone network device

Definitions

  • the present invention relates generally to mobile radio systems.
  • these systems are subject to standardization, and for more information one can refer to the corresponding standards, published by the corresponding standardization bodies.
  • circuit mode traffic is transported in dedicated resources or channels permanently allocated to a user for the duration of a call.
  • packet mode traffic is transported in resources or channels shared between several users. The circuit mode thus makes it possible to guarantee the transfer times for each user, but does not allow efficient use of the resources available to all of the users. On the contrary, the packet mode allows efficient use of all of the available resources, but does not guarantee transfer times. Circuit mode and packet mode are differentiated not only by different resource allocation techniques, but also by different protocol architectures.
  • the general architecture of mobile radiocommunication systems is recalled in FIG. 1, it essentially comprises: a radio access network 1, or RAN (for “Radio Access Network”), a core network 4, or CN (for “ Core Network ”).
  • RAN radio access network
  • CN for “ Core Network ”.
  • the RAN is made up of base stations 2 and base station controllers 3. It is in relation on the one hand with mobile terminals via an interface 6 also called radio interface, and on the other hand with CN 4 via an interface 7.
  • CN 4 is in contact with external networks, not specifically illustrated, such as PSTN ("Public Switched Telephone Network”), PDN (“Packet data Network”), ... etc.
  • BSS Base Station Subsystem
  • BTS Base Transceiver Station
  • BSC Base Station Controller
  • MS Mobile Station
  • PCU Packet Control Unit
  • CN includes: - for circuit mode, 2G-MSC type entities (where 2G is used for
  • the interface 7 includes an interface called interface “A” to entities of type 2G-MSC, and an interface called interface “Gb” to entities of type 2G-SGSN.
  • GSM EDGE Radio Access Network (“GSM EDGE Radio Access Network”, where EDGE is used for “Enhanced Data rates for GSM Evolution”) correspond to evolutions of GSM type systems, aiming to offer third generation services, both for real-time applications only for non-real-time applications.
  • the aim is in particular to be able to support services of the IMS (“IP Multimedia Sub-system” type, where IP is used for “Internet Protocol”).
  • IP Multimedia Sub-system IP Multimedia Sub-system
  • IP IP Multimedia Sub-system
  • UMTS Universal Mobile Telecommunication System
  • the architecture of third generation UMTS type systems is recalled in FIG. 3.
  • the RAN is called UTRAN
  • the base stations are called Node B
  • the base station controllers are called RNC
  • Radio Network Controller Radio Network Controller
  • UE User Equipnnent
  • CN includes: for circuit mode, 3G-MSC type entities (where 3G is used for “3 rd Generation” and MSC is used for “Mobile Switching Center”), for packet mode, 3G-SGSN type entities (where 3G is used for "3" * Generation "and SGSN is used for" Serving GPRS Support
  • the interface 7 includes an interface called the “lu-CS” interface to the entities of the 3G-MSC type, and an interface called the “lu-PS” interface to the entities of the type 3G-SGSN.
  • the architecture initially proposed for GSM / GERAN type systems is recalled in FIG. 4. It has thus been proposed to introduce into GSM / GERAN type systems, in addition to the existing “A” and “Gb” interfaces, an “lu-CS” type interface to 3G-MSC type entities and an “lu-PS” type interface to 3G-SGSN type entities.
  • an “lu-CS” type interface to 3G-MSC type entities and an “lu-PS” type interface to 3G-SGSN type entities.
  • it is now recognized that such an approach requires complex and costly adaptations, in particular in the layer 2 and 3 radio protocols.
  • this last approach includes the following improvements, with a view to evolving the so-called "A / Gb" mode towards a so-called “A / Gb +” mode: - multiple and parallel data flows between BSS and MS, handover (or handover) for real-time services in packet mode, real-time service support by the radio part (or RAN), real-time service support by the network part (or CN), - IMS service support , improvement of security mechanisms.
  • This new combination consists of a channel allocated for data transfer in packet mode, or PDTCH channel (“Packet Data Transfer Channel”) and a dedicated signaling channel in circuit mode or SACCH channel (“Slow Associated Control Channel”), the latter channel being used for such a transfer of radio measurements from the mobile station to the network.
  • PDTCH Packet Data Transfer Channel
  • SACCH Signaling Channel
  • SACCH Slow Associated Control Channel
  • Packet Associated Control Channel uses an RLC / MAC type protocol, these two protocols ending in different network nodes (BTS for LAPDm, PCU for RLC / MAC). Furthermore, the PDTCH channel is a uni-directional channel while real-time services tend to require bi-directional channels. Even for streaming traffic, which is mainly a one-way application, it seems difficult to allocate the return direction to other users, since these users would most likely generate traffic in the other direction, where a preemption of resources for “streaming” traffic in an unacceptable way.
  • the object of the present invention is in particular to propose another approach for supporting real-time services on a “Gb” type interface, making it possible in particular to avoid all or part of the drawbacks mentioned above, or even requiring very few adaptations by compared to existing architectures.
  • One of the objects of the present invention is a method for supporting real-time traffic in a mobile radiocommunication system, as defined in the claims.
  • Another object of the present invention is radio access network equipment for mobile radiocommunication system, comprising means for implementing such a method.
  • Another object of the present invention is a core network equipment for a mobile radio communication system, comprising means for implementing such a method.
  • FIG. 1 is a diagram intended to recall the general architecture of a mobile radiocommunication system
  • - Figure 2 is a diagram intended to recall the general architecture of a second generation system of GSM type
  • Figure 3 is a diagram intended to recall the general architecture of a system of third generation of UMTS type
  • FIG. 4 is a diagram intended to recall a general architecture initially proposed for a GERAN type system
  • FIGS. 5a and 5b are diagrams intended to illustrate, by comparison, the evolution proposed by the present invention for the general architecture of a GERAN type system
  • FIG. 6 is a diagram intended to illustrate an example of implementation of a procedure according to the invention.
  • the present invention suggests using existing radio channels and protocols, used for real-time services when these are relayed via the MSC. Instead of using shared channels to exchange data units or PDUs ("Packet Data unit") from / to the SGSN, the idea is to use dedicated (or "dedicated") channels channels ”). If both real-time and non-real-time services are to be supported simultaneously, existing DTM (Dual Transfer Mode) procedures can be used to control the establishment and release of the different data streams. It is briefly recalled that the DTM functionality is a functionality making it possible to simultaneously support the two types of services (in circuit mode and in packet mode), for mobile stations able to simultaneously support these two types of service, by providing for coordination by the BSS resources required for each mode. For a detailed description of this functionality, reference may also be made to the corresponding specifications published by the standardization bodies.
  • FIGS. 5a and 5b The development proposed according to the invention can be illustrated by comparison of FIGS. 5a and 5b.
  • the equipment illustrated in FIGS. 5a and 5b are those already presented in relation to FIG. 2, namely BTS, BSC, MSC (or 2G-MSC), SGSN (or 2G-SGSN); in addition, the connection between an MSC and an external network of PSTN type, via an entity of type G-MSC ("Gateway-MSC”) has been illustrated in FIGS. 5a and 5b; similarly the connection between an SGSN and an external network of PDN type, via an entity of type GGSN ("Gateway GPRS Support Node”) has been illustrated.
  • G-MSC entity of type G-MSC
  • GGSN Gateway GPRS Support Node
  • FIG. 5a corresponds to a conventional architecture, in which the real time services relayed via an MSC are transported via dedicated channels on the radio interface.
  • FIG. 5b corresponds to an architecture according to the invention, in which the real time services relayed via an SGSN are transported via dedicated channels on the radio interface.
  • PCU Packet Control
  • Circuit mode calls are transported using dedicated channels, i.e. permanently allocated for the duration of the call, while packet calls are transported using shared channels, i.e. shared with other users.
  • the invention proposes to support real-time services in the unit connected to the “Gb” interface through the following functions: - link relocation support “Gb” when the mobile station changes cells and when the new cell is controlled by a BSS different from the BSS controlling the old cell, and when a real-time session is in progress through the “Gb” interface, PFC (“Packet Flow Context”) procedure support to negotiate the parameters QoS with SGSN during activation / modification of PDP context,
  • the unit connected to the “Gb” interface triggers the establishment / modification of a dedicated channel, - the real-time data units received from / to the "Gb” interface are transported on the radio interface by means of dedicated channels, when a "handover" is required, the existing procedures and mechanisms defined for the dedicated channels are used; the only difference is that the MSC is not informed; instead, the unit connected to the "Gb” interface is informed, and ensures if necessary a "Gb" link re-location.
  • MAC Medium Access Control
  • RLC Radio Link Control
  • LLC for “Logical Link Control” in English
  • LLC frames are formed, in the LLC layer, from data units received from a higher level, or network layer, via an adaptation layer or SNDCP (“Subnetwork Dependent Convergence Protocol ”).
  • SNDCP Subnetwork Dependent Convergence Protocol
  • LLC-PDU data units for “LLC-Protocol Data Units”.
  • the LLC-PDU data units are then segmented in the RLC / MAC layer, so as to form blocks called RLC data blocks (or "RLC data blocks").
  • RLC data blocks are then put into the format required for transmission over the radio interface, in the physical layer.
  • Radio Resource Management Radio Resource Management
  • mobility management or MM Mobility Management
  • session management or SM Session Management
  • LL Logical Link Control
  • RR Radio Resource Management
  • SM Session Management
  • LL Logical Link Control
  • packet mode a mode known as “packet transfer mode”, in which resources are temporarily allocated, when data is actually at transmit during a communication, these resources forming a temporary virtual channel or TBF (“Temporary Block Flow”) allowing a transfer of data between mobile station and network, for a given direction of transmission, a mode called “packet idle mode” , in which no TBF is established.
  • TBF Temporal Block Flow
  • circuit mode the mode in which resources are allocated to a mobile station is called “dedicated mode”, these resources then being dedicated resources allocated to the mobile station for the duration of the call.
  • both dedicated resources and resources shared are allocated to the mobile station at the same time, said mobile station is in "dual transfer mode".
  • a mobile station When it is switched on, a mobile station is also called in standby mode, or "idle mode".
  • GPRS Attachment or “GPRS Attach”
  • GPRS Attachment a procedure known as “GPRS Attachment” (or “GPRS Attach”) is defined, allowing a mobile station to switch from “idle mode” to a mode called “GPRS Attachment”. "(Or” GPRS attached "), in which it can access GPRS services.
  • GPRS Attachment or “GPRS Attach”
  • GPRS Attachment a procedure known as “GPRS Attachment” (or “GPRS Attach”) is defined, allowing a mobile station to switch from “idle mode” to a mode called “GPRS Attachment”. "(Or” GPRS attached "), in which it can access GPRS services.
  • CCCH Common Control CHannel
  • PCCCH Packet Common Control CHannel
  • PDCH Packet Data Channel
  • the PDCH data channel includes a traffic channel or PDTCH ("Packet Data Trafic Channel”), and a signaling channel or PACCH ("Packet Associated Control CHannel").
  • PDTCH Packet Data Trafic Channel
  • PACCH Packet Associated Control CHannel
  • the CCCH channel itself includes a certain number of channels such as in particular a PCH (“Paging CHannel”) channel.
  • the PCCCH channel itself includes a certain number of channels such as in particular a PPCH (“Packet Paging CHannel”) channel.
  • PDP packet data protocol
  • the PDP context contains the information necessary for the transfer of data between MS and GGSN (routing information, QoS profile, etc.).
  • signaling relating to multimedia call session control has so far been defined for UMTS type technologies.
  • Such signaling thus typically comprises the establishment of an RRC connection between a mobile station and a RAN, followed by the establishment of a UMTS carrier to transport the signaling relating to the SIP protocol.
  • the RRC protocol for “Radio Resource Control” is defined in the 3GPP TS 25.331 standard.
  • the SIP protocol (“Session Initiation Protocol") as well as the SDP protocol (“Session Description Protocol”) which is linked to it have been defined by the IETF ("Internet Engineering Task Force") which is the standardization body for the Internet protocol, or IP (for “Internet Protocol”).
  • SI The main stages of such signaling are the following, denoted SI, S2, S3.
  • SI the sub stages of such signaling.
  • S-CSCF Server-Call Session Control Function
  • P-CSCF Proxy-Call Session Control Function
  • the stage SI corresponds essentially to a stage preliminary to the establishment of session.
  • Step SI uses a procedure known as activation of a data protocol context in packet mode, or PDP context (or “PDP Context”, for “Packet Data Protocol Context”), necessary for the transport of multimedia session control signaling.
  • PDP context or “PDP Context”, for “Packet Data Protocol Context”
  • a PDP context comprises a set of UMTS carrier parameters, such as in particular quality of service parameters, or QoS (for “Quality of Service”), etc.
  • QoS Quality of Service
  • the step SI itself essentially comprises the following steps.
  • a request for activation of a PDP context is transmitted from the UE to the RAN, with the corresponding end-to-end QoS parameters for the UMTS carrier of SIP level signaling.
  • the 3G-SGSN commands the establishment of a radio access carrier (or RAB, or "Radio Access Bearer") so that a medium is available between UE and 3G-SGSN, meeting the quality of service constraints.
  • RAB radio access carrier
  • the RAN When the RAN receives such a request, after a call admission check, it establishes a radio carrier (or RB, or "Radio Bearer”) on the radio interface (step SI 3) and a read carrier (or " lu bearer ”) on the" lu "interface. The establishment of the RAB can then be confirmed (step SI 4) and the PDP context activated (step SI 5), after negotiation with the 3G-GGSN (step S1 6, SI 7).
  • a radio carrier or RB, or "Radio Bearer”
  • a read carrier or " lu bearer ”
  • Step S2 essentially corresponds to the establishment of the multimedia session at the level of the SIP protocol.
  • This step includes negotiation to determine the characteristics for the session being established.
  • This negotiation notably includes a codec negotiation, making it possible to determine a list or set of codecs capable of being supported jointly by the two parties to the call and authorized by all the intermediate network nodes, for this session.
  • the codecs determine, both in the mobile stations and in the radio access network (in particular in the base stations) as well as in the core network, how to perform the source coding and the channel coding necessary in particular for the transmission on the radio interface.
  • codecs for speech coding, in a GSM type system, there are different types of codecs: full speed (or FR, for "Full Rate”), improved full speed (or EFR, for "Enhanced Full Rate”) , half-speed (or HR, for "Half Rate”), or even AMR (for "Adaptive Multi-Rate coding”), the latter being particularly advantageous in that it makes it possible to optimize the quality of service (in l occurrence by selecting at each instant, according to the transmission conditions encountered, an optimal combination of a given source coding and a given channel coding).
  • Step S2 essentially comprises the following steps.
  • RB has been established for SIP signaling (by means of the previous step SI), a first task consists of the SIP client discovering its P-CSCF. Then, he will have to declare himself and register with his S-CSCF, which will call on other entities network core. Finally, during a session establishment, a request called “SIP Invite” is sent to the called party via the P-CSCF and S-CSCF entities.
  • This message contains an SDP datagram which indicates for each media stream that the calling UE wishes to establish, a certain number of media parameters such as: media type, combination of QoS attributes, list of codecs capable of being supported. for this session, ... etc.
  • Step S3 essentially corresponds to an end of session establishment, and includes a resource allocation step, based on the media flow characteristics (in terms of QoS attributes, negotiated coding, etc.) thus determined. in step S2.
  • Step S3 also uses a PDP context activation procedure, also called a secondary PDP context activation procedure (to distinguish it from the primary context activation procedure used in step S1).
  • Step S3 is similar to step S1, except that the UMTS carrier parameters to be established now correspond to the needs determined in step S2.
  • Step S3 itself comprises steps which are similar to those of step S1, and which for this reason will not be re-described.
  • Step S3 thus comprises the establishment of an RAB for this secondary PDP context.
  • the RAN performs admission control and accepts or rejects the call.
  • each service is defined by quality of service parameters or attributes (such as guaranteed bit rate, transfer delay, etc.), all of these parameters or attributes forming a profile quality of service.
  • quality of service management has been improved between versions R97 and R99 of the standard.
  • the mobile station can indicate QoS parameters when it requires the establishment of a TBF (for “Temporary Block Flow”) in the uplink direction, using a so-called two-phase access procedure.
  • TBF Temporal Block Flow
  • each LLC PDU received from the SGSN contains an information element called "QoS Profile Information Element", giving limited information on the quality of service.
  • the PDP context (or "PDP context") created during the establishment of a data session contains the information necessary for the transfer of data between MS and GGSN (routing information, QoS profile, ... etc.) .
  • PDP context When activating a PDP context, if the PFC functionality is implemented in the BSS and the SGSN, the latter can request QoS parameters from the BSS which can negotiate all or part of these parameters according to its load and capabilities.
  • the data associated with a PDP context and therefore with a given QoS are well identified not only in the core network CN but also in the radio access network RAN. This ensures that the QoS offered for the PDP context is negotiated between all the network nodes, and it thus becomes possible to guarantee certain quality of service attributes. It is thus possible to obtain that a guaranteed bit rate or a maximum transfer delay is offered, which makes it possible to offer real-time services.
  • the BSS is able to offer the required throughput and also to transfer the LLC PDUs received within the limits of the maximum transfer delay. For this, it is necessary that there is as little queuing as possible in the BSS (it is recalled that the queuing is specific to the transfer used in the systems in packet mode), and that the transfer interruptions (due in particular to cell re-selections, as mentioned above) are as short as possible. This requires that the BSS always know the QoS specifications for the transfer of such data, or in other words that it has a context containing associated QoS profile information.
  • the SGSN may at any time request the creation of a context called "BSS Packet Flow Context" (or PFC), in particular when activating a PDP context.
  • BSS Packet Flow Context or PFC
  • FIG. 6 is a diagram intended to illustrate an example of implementation of a method according to the invention.
  • the present invention covers both the case of a call received by the mobile station (or “MT Call”, for “Mobile Terminating Call”) as well as the case of a call sent by the mobile station (or “MO Call “, for” Mobile Originating Call ”) through the packet domain (or" PS domain ").
  • a step in these different scenarios is the establishment of a dedicated channel, on creation of a PFC.
  • the 3GPP specifications concerning the IMS (23.228 and 24.228) define the different flows for call establishment, and the purpose is not here to recall them.
  • an important step which more particularly constitutes one of the objects of the present invention is the step of reserving resources.
  • MO session establishment this occurs between the sending of the "Final SDP ”and“ Resource Reservation successful ”.
  • MT session establishment this occurs after the “Final SDP” message has been received from the calling party.
  • the MS triggers a secondary PDP context activation for the media stream, whose QoS parameters have been negotiated at the SIP level. For this, the
  • MS requires uplink TBF (or UL TBF, for "Uplink TBF") on shared channels.
  • the SGSN When the SGSN receives the message “ACTIVATE PDP CONTEXT REQUEST from the MS, it creates the PDP context in the SGSN and then sends a CREATE BSS PFC message on the Gb interface, in order to ask the BSS to reserve the necessary radio resources for the real-time media stream.
  • the required QoS indicates real-time characteristics. It is proposed here to authorize the BSS to allocate dedicated resources. Two methods or procedures are proposed in the case where the BSS can allocate such resources in correspondence with the required QoS: re-use as much as possible the existing techniques by sending a paging to the MS, or introduce a new allocation message . It can be noted that at this stage the MS is necessarily in the GMM READY state since an LLC PDU in the uplink direction has just been sent, containing the message ACTIVATE PDP CONTEXT REQUEST. (3a) In a first procedure, the BSS generates a "paging" to the MS.
  • an MS can receive a “CS paging” (or “paging” for circuit mode services) only if this “CS paging” is received from the MSC. It is proposed here that the BSS generates a “paging” for real-time services after having received a request from the SGSN. Depending on the radio state of the MS, the "paging" message can be sent either on common control channels or on the PACCH of a TBF in progress. This would be similar to "CS paging", with the exception that an indication would be present to indicate that this "paging" comes from the PS ("Packet Switched”) or packet mode domain.
  • PS Packet Switched
  • the MS will return to the common control channels and initiate a random access procedure by requesting dedicated resources (another option would be to improve DTM (Dual Transfer Mode) procedures in a way authorize the MS to initiate dedicated access through the PACCH of a TBF in progress).
  • the BSS will then allocate dedicated resources and the MS will establish the Layer 2 signaling link.
  • a GPRS INFORMATION message containing the TLLI identifier ("Temporary Logical Link Identifier") specific to the mobile station MS.
  • This message can also contain an empty LLC frame superimposed (“piggybacked” in English) on the SABM message.
  • the TLLI will be returned to the BSS, so that the BSS can associate the newly established connection with the request received in the CREATE BSS PFC message.
  • an intracellular “handover” can be carried out to allocate resources in correspondence with the request received from the SGSN (or in correspondence with the QoS negotiated with the SGSN) if such resources are available.
  • the GPRS INFORMATION message can be sent on the dedicated channel DCCH (“Dedicated Control Channel”) once established. Note that any other message containing the MS TLLI can be used.
  • the allocated resources should correspond to the required QoS.
  • the BSS then sends an acknowledgment to the SGSN for the creation of the PFC. Note that if the BSS cannot allocate resources to achieve the required QoS, it can first try to negotiate the parameters QoS, and if the negotiation succeeds, it can then carry out the establishment of dedicated channels.
  • Activation of the PDP context is then completed (through the establishment of a TBF, or by using the GPRS INFORMATION message, or by using an existing TBF if it is still in progress),
  • the real-time PDUs are routed as follows: in the network direction to MS: GGSN -> SGSN (Interface "Gn"), SGSN -> BSC (interface "Gb”), BSC- BTS (Interface Abis), BTS - »MS
  • Gn (“Gn” interface) On the “Gb” and “Gn” interfaces the PDUs are routed like packets. On the Abis and radio interfaces, the PDUs are transported on dedicated channels.
  • step 61 indicates that the establishment of a call is in progress for a real-time media stream, the “Final SDP” has just been sent (in the case MO) or received (in the case MT), - step 62 indicates that a secondary PDP context is created in the
  • step 63 indicates that the BSS has received a “PFC Creation Request” for a real time flow, it establishes dedicated resources, step 64 indicates that the MS activates the dedicated resources allocated, - step 65 indicates that multi-frame operation is now established, the contention is resolved, and the BSS knows the TLLI of the new connection.
  • a "handover" is carried out if necessary, step 66 indicates that the SIP call establishment can then occur, the option corresponding to the first procedure indicated above has been noted 67 - the option corresponding to the second procedure indicated above has been noted 68.
  • One of the advantages of the invention is that the existing procedures or protocols are re-used. In particular, there is no need to introduce a new channel combination, nor a TBF handover.
  • the impacts on a mobile station according to the R99 version of the standard supporting the DTM (Dual Transfer Mode) mode are reduced to a minimum (the PDP context for which a dedicated channel is allocated must be indicated to the mobile station).
  • LAPDm can be reused. All signaling can be done through the existing SACCH and FACCH channels. This does not prevent the improvement of procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles comportant un réseau d'accès radio et un cœur de réseau, procédé dans lequel du trafic temps réel supporté en mode paquet dans le cœur de réseau est supporté dans le réseau d'accès radio au moyen d'une allocation de canaux dédiés.

Description

PROCEDE POUR SUPPORTER DU TRAFIC TEMPS REEL DANS UN SYSTEME DE RADIOCOMMUNICATIONS MOBILES
La présente invention concerne d'une manière générale les systèmes de radiocommunications mobiles. D'une manière générale, ces systèmes font l'objet de normalisation, et pour plus d'informations on pourra se référer aux normes correspondantes, publiées par les organismes de normalisation correspondants.
D'une manière générale, dans ces systèmes, on peut distinguer différents types de services, en fonction de la qualité de service requise. Notamment, on peut distinguer des services temps réel, correspondant à du trafic sensible aux délais de transfert (tel que notamment la voix, ou encore du trafic à flux continu ou « streaming »), et des services non temps réel, correspondant à du trafic non sensible aux délais de transfert (tel que notamment le transfert de données).
D'une manière générale, dans ces systèmes, on peut aussi distinguer différents types de services, selon les techniques utilisées pour les supporter. On peut ainsi distinguer les services en mode circuit et les services en mode paquet. En mode circuit, le trafic est transporté dans des ressources ou canaux dédiés alloués en permanence à un utilisateur pour la durée d'un appel. En mode paquet, le trafic est transporté dans des ressources ou canaux partagés entre plusieurs utilisateurs. Le mode circuit permet ainsi de garantir les délais de transfert pour chaque utilisateur , mais ne permet pas une utilisation efficace ' des ressources disponibles pour l'ensemble des utilisateurs. Au contraire, le mode paquet permet une utilisation efficace de l'ensemble des ressources disponibles, mais ne permet pas de garantir les délais de transfert. Le mode circuit et le mode paquet se différencient non seulement par des techniques différentes d'allocation de ressources, mais aussi par des architectures de protocoles différentes.
Les systèmes de deuxième génération, de type GSM (« Global System for Mobile communications ») ont plutôt été conçus initialement pour supporter du trafic temps réel (essentiellement de la voix) en mode circuit. Des fonctionnalités supplémentaires ont ensuite été introduites dans ces systèmes, correspondant à la fonctionnalité GPRS (« General Packet Radio Service »), pour leur permettre de supporter du trafic non temps réel en mode paquet. L'architecture générale des systèmes de radiocommunications mobiles est rappelée sur la figure 1 , elle comporte essentiellement : un réseau d'accès radio 1 , ou RAN (pour « Radio Access Network »), un cœur de réseau 4, ou CN (pour « Core Network »). Dans cette architecture générale, le RAN est formé de stations de base 2 et de contrôleurs de stations de base 3. Il est en relation d'une part avec des terminaux mobiles via une interface 6 appelée aussi interface radio, et d'autre part avec le CN 4 via une interface 7. Le CN 4 est en relation avec des réseaux extérieurs, non illustrés spécifiquement, tels que PSTN (« Public Switched Téléphone Network »), PDN (« Packet data Network »), ...etc.
L'architecture générale des systèmes de deuxième génération de type GSM est rappelée sur la figure 2. Dans ces systèmes, le RAN est appelé BSS ("Base Station Subsystem"), les stations de base sont appelées BTS ("Base Transceiver Station"), les contrôleurs de stations de base sont appelés BSC ("Base Station Controller"), et les terminaux mobiles sont appelés MS (« Mobile Station »). Les fonctionnalités propres aux services en mode paquet sont en général supportées par une entité particulière appelée PCU (« Packet Control Unit »), non illustrée spécifiquement, prévue en général dans le BSS.
Dans les systèmes de deuxième génération de type GSM, le CN comporte: - pour le mode circuit, des entités de type 2G-MSC (où 2G est utilisé pour
« 2nd Génération » et MSC est utilisé pour « Mobile Switching Center »), pour le mode paquet, des entités de type 2G-SGSN (où 2G est utilisé pour « 2nd Génération » et SGSN est utilisé pour « Serving GPRS Support Node»). Ainsi, dans les systèmes de deuxième génération de type GSM, l'interface 7 comporte une interface appelée interface « A » vers les entités de type 2G-MSC, et une interface appelée interface « Gb » vers les entités de type 2G-SGSN.
Les systèmes de type GERAN (« GSM EDGE Radio Access Network », où EDGE est utilisé pour « Enhanced Data rates for GSM Evolution ») correspondent à des évolutions des systèmes de type GSM, visant à offrir des services de troisième génération, aussi bien pour des applications temps réel que pour des applications non temps réel. Le but est notamment de pouvoir supporter des services de type IMS (« IP Multimedia Sub-system »,où IP est utilisé pour « Internet Protocol »). Pour cela, il a initialement été proposé d'aligner les services offerts par les systèmes de type GERAN sur ceux offerts par les systèmes de troisième génération de type UMTS (« Universal Mobile Télécommunication System ») en connectant des BSS de type GERAN au CN 3G via les interfaces lu, lesdites interfaces étant utilisées pour connecter l'UTRAN (pour « UMTS Terrestrial Radio Access Network) au CN 3G.
L'architecture des systèmes de troisième génération de type UMTS est rappelé sur la figure 3. Dans ces sytèmes, le RAN est appelé UTRAN , les stations de base sont appelées Node B, les contrôleurs de stations de base sont appelés RNC
(« Radio Network Controller »), et les terminaux mobiles sont appelés UE (« User Equipnnent »).
Dans les sytèmes de troisième génération de type UMTS, le CN comporte: pour le mode circuit, des entités de type 3G-MSC (où 3G est utilisé pour « 3rd Génération » et MSC est utilisé pour « Mobile Switching Center »), pour le mode paquet, des entités de type 3G-SGSN (où 3G est utilisé pour « 3"* Génération » et SGSN est utilisé pour « Serving GPRS Support
Node»). Ainsi, dans les systèmes de troisième génération de type UMTS, l'interface 7 comporte une interface appelée interface « lu-CS » vers les entités de type 3G-MSC, et une interface appelée interface « lu-PS » vers les entités de type 3G-SGSN. L'architecture initialement proposée pour les sytèmes de type GSM/GERAN est rappelée sur la figure 4. Il a ainsi été proposé d'introduire dans les systèmes de type GSM/GERAN, en plus des interfaces « A » et « Gb » existantes, une interface de type « lu-CS » vers des entités de type 3G-MSC et une interface de type « lu-PS » vers des entités de type 3G-SGSN. Cependant, il est maintenant reconnu qu'une telle approche nécessite des adaptations complexes et coûteuses, notamment dans les protocoles radio de couches 2 et 3.
C'est pourquoi une autre approche a maintenant été proposée, qui consiste à supporter les mêmes services que ceux supportés au moyen des interfaces « lu- CS », « lu-PS » mais au moyen des interfaces existantes « A », « Gb ». Le but est notamment de pouvoir supporter des services de type IMS (« IP Multimedia Sub- system » ) via l'interface « Gb ». Pour mémoire, aujourd'hui l'interface « Gb » est seulement capable de supporter des services non temps réel (éventuellement du trafic à flux continu ou « streaming »), et des services temps réel peuvent seulement être supportés via l'interface « A ».
D'une manière générale, cette dernière approche inclut les améliorations suivantes, en vue de faire évoluer le mode dit « A/Gb » vers un mode dit « A/Gb+ »: - flux de données multiples et en parallèle entre BSS et MS, transfert intercellulaire (ou « handover ») pour des services temps réel en mode paquet, support de services temps réel par la partie radio (ou RAN), support de services temps réel par la partie réseau (ou CN), - support de services IMS, amélioration des mécanismes de sécurité. Jusqu'à présent, la seule proposition pour le support de services temps réel en mode paquet sur l'interface « Gb » a été de prévoir un transfert intercellulaire ou « handover » pour les services en mode paquet. On rappelle que les procédures de transfert intercellulaire ou « handover » sont propres au mode circuit. Selon ces procédures, des ressources sont réservées dans une nouvelle cellule alors qu'une station mobile est encore connectée à une ancienne cellule, ce qui permet, au prix d'une certaine complexité, de garantir les délais de transfert. Au contraire, les procédures de re-sélection de cellule sont propres au mode paquet. Selon ces procédures, des ressources ne sont allouées à une station mobile dans une nouvelle cellule que lorsque la station mobile est connectée à la nouvelle cellule, ce qui simplifie les procédures mais ne garantit pas les délais de transfert.
La proposition mentionnée ci-dessus permet d'introduire pour le mode paquet des mécanismes similaires à ceux utilisés dans les procédures de transfert intercellulaire ou « handover » pour le mode circuit. De plus, des procédures ont été proposées pour permettre à une station mobile de reporter régulièrement des mesures radio au réseau en vue de permettre à ce dernier de sélectionner une nouvelle cellule, comme dans le mode circuit. Pour cela, une nouvelle combinaison de canaux sur l'interface radio a été proposée, notamment dans le document « Tdoc G2-020553, Agenda Item 5.3, 3GPP TSG GERAN WG2 Sophia-Antipolis, France, 27-31 May 2002 ». Cette nouvelle combinaison consiste en un canal alloué pour un transfert de données en mode paquet, ou canal PDTCH (« Packet Data Transfer Channel ») et en un canal de signalisation dédié en mode circuit ou canal SACCH (« Slow Associated Control Channel »), ce dernier canal étant utilisé pour un tel report de mesures radio de la station mobile vers le réseau.
Ainsi que l'a observé le demandeur, une telle proposition a notamment les inconvénients suivants: la station de base BTS et la station mobile MS doivent supporter une nouvelle combinaison de canaux, l'entité PCU (dans laquelle sont mises en œuvre les fonctionnalités propres au mode paquet) doit traiter des reports de mesures et implémenter des algorithmes de transfert intercellulaire ou « handover», - une nouvelle procédure doit être introduite sur l'interface radio pour supporter cette nouvelle combinaison, des problèmes se posent au niveau de l'architecture de ces systèmes puisque le SACCH utiliserait un protocole de type LAPDm (« Link Access Protocol for the Dm channel ») comme protocole de couche 2 alors que le canal de signalisation associé au canal PDTCH, ou canal PACCH
(« Packet Associated Control Channel »), utilise un protocole de type RLC/MAC, ces deux protocoles se terminant dans des nœuds de réseau différents (BTS pour LAPDm, PCU pour RLC/MAC). Par ailleurs, le canal PDTCH est un canal uni-directionnel alors que les services temps réel tendent à requérir des canaux bi-directionnels. Même pour du trafic à flux continu ou « streaming », qui est prinicipalement une application unidirectionnelle, il semble difficile d'allouer le sens retour à d'autres utilisateurs, puisque ces utilisateurs généreraient très vraisemblablement du trafic dans l'autre direction, d'où une préemption de resources pour du trafic de « streaming » d'une manière inacceptable.
La présente invention a notamment pour but de proposer une autre approche pour le support de services temps réel sur une interface de type « Gb », permettant notamment d'éviter tout ou partie des inconvénients mentionnés précédemment, ou encore nécessitant très peu d'adaptations par rapport aux architectures existantes.
Un des objets de la présente invention est un procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles, tel que défini dans les revendications. Un autre objet de la présente invention est un équipement de réseau d'accès radio pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé.
Un autre objet de la présente invention est un équipement de cœur de réseau pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé.
Un autre objet de la présente invention est une station mobile pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un tel procédé. D'autres objets et caractéristiques de la présente invention apparaîtront à la lecture de la description suivante d'un exemple de réalisation, faite en relation avec les dessins ci-annexés dans lesquels: la figure 1 est un schéma destiné à rappeler l'architecture générale d'un système de radiocommunications mobiles, - la figure 2 est un schéma destiné à rappeler l'architecture générale d'un système de deuxième génération de type GSM, la figure 3 est un schéma destiné à rappeler l'architecture générale d'un système de troisième génération de type UMTS, la figure 4 est un schéma destiné à rappeler une architecture générale proposée initialement pour un système de type GERAN, les figures 5a et 5b sont des schémas destinés à illustrer, par comparaison, l'évolution proposée par la présente invention pour l'architecture générale d'un système de type GERAN, la figure 6 est un schéma destiné à illustrer un exemple de mise en œuvre d'un procédé suivant l'invention.
La présente invention suggère d'utiliser les canaux et protocoles radio existants, utilisés pour les services temps réel lorsque ceux-ci sont relayés via le MSC. Au lieu d'utiliser des canaux partagés (ou « shared channels ») pour échanger des unités de données ou PDUs (« Packet Data unit ») de/vers le SGSN, l'idée est d'utiliser des canaux dédiés (ou « dedicated channels »). Si des services temps réel et non temps réel doivent être supportés simultanément, les procédures DTM (« Dual Transfer Mode ») existantes peuvent être utilisées pour contrôler l'établissement et le relâchement des différents flux de données. On rappelle brièvement que la fonctionnalité DTM est une fonctionnalité permettant de supporter simultanément les deux types de services (en mode circuit et en mode paquet), pour les stations mobiles pouvant supporter simultanément ces deux types de services, en prévoyant une coordination par le BSS des ressources nécessaires à chacun des modes. Pour une description détaillée de cette fonctionnalité, on pourra aussi se référer aux spécifications correspondantes publiées par les organismes de normalisation.
L'évolution proposée selon l'invention peut être illustrée par comparaison des figures 5a et 5b. Les équipements illustrés sur les figures 5a et 5b sont ceux déjà présentés en relation avec la figure 2, à savoir BTS, BSC, MSC (ou 2G-MSC), SGSN (ou 2G-SGSN) ; de plus, la connexion entre un MSC et un réseau extérieur de type PSTN, via une entité de type G-MSC (« Gateway-MSC ») a été illustrée sur les figures 5a et 5b; de même la connexion entre un SGSN et un réseau extérieur de type PDN, via une entité de type GGSN (« Gateway GPRS Support Node») a été illustrée. Les interfaces « Abis » entre BTS et BSC, « Gn » entre SGSN et GGSN, et « Gi » entre GGSN et PDN ont également été illustrées. Le but étant notamment de pouvoir supporter des services de type IMS, dans la figure 5b, PDN a été remplacé par IMS.
La figure 5a correspond à une architecture classique, dans laquelle les services temps réel relayés via un MSC sont transportés via des canaux dédiés sur l'interface radio.
La figure 5b correspond à une architecture selon l'invention, dans laquelle les services temps réel relayés via un SGSN sont transportés via des canaux dédiés sur l'interface radio.
Dans l'architecture GSM existante, il est prévu deux types d'unités pour traiter les deux types d'appels, en mode circuit et en mode paquet. Ces deux types d'unités peuvent ou non être intégrées physiquement dans un même équipement.
L'unité chargée de traiter les appels en mode paquet, ou PCU (« Packet Control
Unit ») est en général prévue dans le BSS.
Ainsi, généralement, il y a dans le BSS une unité connectée à l'interface « A » et qui traite les appels en mode circuit, et une autre unité connectée à l'interface « Gb » et qui traite les appels en mode paquet. Les appels en mode circuit sont transportés au moyen de canaux dédiés, c'est-à-dire alloués en permanence pour la durée de l'appel, alors que les appels en mode paquet sont transportés au moyen de canaux partagés, c'est-à-dire partagés avec d'autres utilisateurs.
L'invention propose de supporter des services temps réel dans l'unité connectée à l'interface « Gb » à travers les fonctions suivantes : - support de re-localisation de lien « Gb » lorsque la station mobile change de cellule et lorsque la nouvelle cellule est contrôlée par un BSS différent du BSS contrôlant l'ancienne cellule, et lorsqu'une session temps réel est en cours à travers l'interface « Gb », support de procédure de PFC (« Packet Flow Context ») pour négocier les paramètres de QoS avec le SGSN lors d'une activation/modification de contexte PDP,
Lorsqu'un PFC est créé/modifié pour un flux de données temps réel, l'unité connectée à l'interface « Gb » déclenche l'établissement/modification d'un canal dédié, - les unités de données temps réel reçues de/vers l'interface »Gb » sont transportées sur l'interface radio au moyen de canaux dédiés, lorsqu'un « handover » est requis, les procédures et mécanismes existants définis pour les canaux dédiés sont utilisés ; la seule différence est que le MSC n'est pas informé ; au lieu de cela, l'unité connectée à l'interface « Gb » est informée, et assure si nécessaire une re-localisation de lien « Gb ». Avant de décrire un exemple de mise en œuvre de la présente invention, on rappelle tout d'abord les protocoles ou procédures propres aux systèmes en mode paquet, ou aux architectures de type IMS, dans la mesure où ils peuvent être utiles à la description de cet exemple.
Selon l'architecture en couches utilisée pour décrire les systèmes en mode paquet, notamment de type GSM/GPRS, on distingue, sur l'interface radio entre MS et BSS: une première couche, ou couche physique, - une deuxième couche, ou couche liaison, elle-même divisée en plusieurs couches: par ordre de niveaux croissants, MAC (pour « Médium Access Control » en anglais), RLC (pour « Radio Link Control » en anglais) et LLC (pour « Logical Link Control » en anglais). De même, on distingue, sur l'interface « Gb » entre BSS et SGSN: une première couche, ou couche physique, une deuxième couche, ou couche liaison, elle-même divisée en plusieurs couches : par ordre de niveaux croissants, « Frame Relay » (en anglais), BSSGP (pour « BSS GPRS Protocol» en anglais), et LLC (pour « Logical
Link Control » en anglais).
Des trames appelées trames LLC (ou « LLC frames » en anglais) sont formées, dans la couche LLC, à partir d'unités de données reçues d'un niveau supérieur, ou couche réseau, via une couche d'adaptation ou SNDCP (« Subnetwork Dépendent Convergence Protocol »). Dans les trames LLC ces unités de données sont appelées unités de données LLC-PDU (pour « LLC-Protocol Data Units »).
Les unités de données LLC-PDU sont ensuite segmentées dans la couche RLC/MAC, de manière à former des blocs appelés blocs de données RLC (ou « RLC data blocks »). Les blocs de données RLC sont ensuite mis au format requis pour transmission sur l'interface radio, dans la couche physique.
En outre, des protocoles de signalisation sont prévus, notamment pour la gestion des ressources radio ou RR (« Radio Resource Management »), la gestion de la mobilité ou MM (« Mobility Management»), la gestion de session ou SM (« Session Management»), le contrôle de lien logique ou LL (« Logical Link Control »), ...etc. On rappelle aussi que, selon le protocole de gestion de ressources radio, différents modes sont possibles pour une station mobile, en mode paquet : un mode dit « packet transfer mode », dans lequel des ressources sont allouées temporairement, lorsque des données sont effectivement à transmettre au cours d'une communication, ces ressources formant un canal virtuel temporaire ou TBF (« Temporary Block Flow ») permettant un transfert de données entre station mobile et réseau, pour un sens de transmission donné, un mode dit « packet idle mode », dans lequel aucun TBF n'est établi.
Par opposition, en mode circuit, le mode dans lequel des ressources sont allouées à une station mobile est appelé « dedicated mode », ces ressources étant alors des ressources dédiées allouées à la station mobile pour la durée de la communication. Dans le cas où à la fois des ressources dédiées et des ressources partagées sont allouées à la station mobile en même temps, ladite station mobile se trouve en « dual transfer mode ».
A sa mise en marche, une station mobile est aussi dite en mode veille, ou « idle mode ». En outre, selon le protocole de gestion de mobilité, on définit une procédure dite d' « attachement GPRS » (ou « GPRS Attach»), permettant à une station mobile de passer du mode « idle mode » à un mode dit « attaché GPRS » (ou « GPRS attached »), dans lequel elle peut accéder à des services GPRS. On définit aussi la procédure inverse de « GPRS Detach ». Une station mobile en mode veille et non attachée GPRS communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés CCCH (« Common Control CHannel »). Une station mobile attachée GPRS et en mode « packet idle mode » communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés PCCCH (« Packet Common Control CHannel ») si de tels canaux sont prévus dans la cellule considérée, sinon par les canaux CCCH. Une station mobile attachée GPRS et dans le mode « packet transfer mode » communique avec le réseau par l'intermédiaire d'échanges de signalisation sur des canaux appelés PDCH (« Packet Data Channel »).
On rappelle que le canal de données PDCH inclut un canal de trafic ou PDTCH (« Packet Data Trafic Channel »), et un canal de signalisation ou PACCH (« Packet Associated Control CHannel »).
On rappelle aussi que le canal CCCH inclut lui-même un certain nombre de canaux tels que notamment un canal PCH (« Paging CHannel »). De même le canal PCCCH inclut lui-même un certain nombre de canaux tels que notamment un canal PPCH (« Packet Paging CHannel »).
On rappelle aussi que lorsqu'une session doit être établie dans un système tel que le GPRS, une procédure d'activation contextuelle de protocole de données en mode paquet (ou PDP, pour « Packet Data Protocol ») doit être lancée. Le contexte de PDP (ou « PDP context ») contient les informations nécessaires au transfert des données entre MS et GGSN (informations de routage, profil de QoS, ...etc.).
On rappelle aussi que dans une architecture de type IMS, une signalisation relative au contrôle de session d'appel multimédia a jusqu'à présent été définie pour des technologies de type UMTS. Une telle signalisation comporte ainsi typiquement l'établissement d'une connexion RRC entre une station mobile et un RAN, suivi de l'établissement d'une porteuse UMTS pour transporter la signalisation relative au protocole SIP. Le protocole RRC, pour « Radio Resource Control » est défini dans la norme 3GPP TS 25.331 . Le protocole SIP (« Session Initiation Protocol ») ainsi que le protocole SDP (« Session Description Protocol ») qui lui est lié ont été définis par l'IETF (« Internet Engineering Task Force ») qui est l'organisme de normalisation pour le protocole Internet, ou IP (pour « Internet Protocol »).
Les principales étapes d'une telle signalisation sont les suivantes, notées SI , S2, S3. Pour simplifier, on ne considère ici qu'un des trois segments en lesquels se décompose le contrôle de session d'appel, en l'occurrence le segment qui va de l'UE appelant à son S-CSCF, les deux autres segments étant le segment qui va de l'UE appelé à son S-CSCF, et le segment qui relie les S-CSCF de l'UE appelant et de l'UE appelé. On rappelle que les entités S-CSCF (« Serving-Call Session Control Function ») et P-CSCF (« Proxy-Call Session Control Function ») sont des entités du réseau de cœur, en charge du contrôle de sessions d'appels multimédia.
L'étape SI correspond essentiellement à une étape préliminaire à l'établissement de session.
L'étape SI utilise une procédure dite d'activation de contexte de protocole de données en mode paquet, ou contexte PDP (ou « PDP Context», pour « Packet Data Protocol Context»), nécessaire au transport de signalisation de contrôle de session multimédia. On rappelle qu'un contexte PDP comporte un ensemble de paramètres de porteuse UMTS, tels que notamment des paramètres de qualité de service, ou QoS (pour « Quality of Service »), ...etc. Cette étape sera suivie ultérieurement d'une autre procédure d'activation de contexte PDP, nécessaire au transport des données liées à la session multimédia elle-même. Ces deux contextes PDP concernant la même adresse IP, l'étape SI sera aussi appelée procédure d'activation de contexte PDP primaire.
L'étape SI comporte elle-même essentiellement les étapes suivantes. Dans une étape SU , une requête d'activation de contexte PDP est transmise de l'UE au RAN, avec les paramètres correspondants de qualité de service de bout en bout (ou « end-to-end QoS ») pour la porteuse UMTS de signalisation de niveau SIP. Dans une étape SI 2, le 3G-SGSN commande l'établissement d'une porteuse d'accès radio (ou RAB, ou « Radio Access Bearer ») de sorte qu'un support soit disponible entre UE et 3G-SGSN, répondant aux contraintes de qualité de service. Lorsque le RAN reçoit une telle requête, après un contrôle d'admission d'appel, il établit une porteuse radio (ou RB, ou « Radio Bearer ») sur l'interface radio (étape SI 3) et une porteuse lu (ou « lu bearer ») sur l'interface « lu ». L'établissement du RAB peut alors être confirmé (étape SI 4) et le contexte PDP activé (étape SI 5), après négociation avec le 3G-GGSN (étape S1 6, SI 7).
L'étape S2 correspond essentiellement à l'établissement de la session multimédia au niveau du protocole SIP. Cette étape inclut une négociation permettant de déterminer les caractéristiques pour la session en cours d'établissement. Cette négociation inclut notamment une négociation de codées, permettant de déterminer une liste ou ensemble de codées capables d'être supportés en commun par les deux parties à l'appel et autorisés par tous les noeuds de réseau intermédiaires, pour cette session.
On rappelle que les codées déterminent, aussi bien dans les stations mobiles que dans le réseau d'accès radio (notamment dans les stations de base) ainsi que dans le coeur de réseau, comment réaliser le codage source et le codage canal nécessaires notamment à la transmission sur l'interface radio. Par exemple, pour le codage de parole, dans un système de type GSM, il existe différents types de codées: plein débit (ou FR, pour "Full Rate"), plein débit amélioré (ou EFR, pour "Enhanced Full Rate"), demi-débit (ou HR, pour "Half Rate"), ou encore AMR (pour "Adaptive Multi- Rate coding"), ce dernier étant particulièrement intéressant en ce qu'il permet d'optimiser la qualité de service (en l'occurrence en sélectionnant à chaque instant, en fonction des conditions de transmission rencontrées, une combinaison optimale d'un codage source donné et d'un codage canal donné). Deux types de codée AMR existent : le codée à bande étroite « Narrowband AMR » et le codée à bande large « Wideband AMR ». Un codée de type « Wideband AMR » offre une qualité de service encore meilleure mais nécessite des débits radio plus importants. Le cas de parole n'est bien sûr qu'un exemple des différentes composantes, ou différents flux de média, formant une session multimédia. L'étape S2 comporte essentiellement les étapes suivantes. Une fois qu'un
RB a été établi pour la signalisation SIP (au moyen de l'étape précédente SI ), une première tâche consiste pour le client SIP à découvrir son P-CSCF. Ensuite, il devra se déclarer et s'enregistrer auprès de son S-CSCF, ce qui fera appel à d'autres entités de coeur de réseau. Enfin, lors d'un établissement de session, une requête appelée « SIP Invite » est envoyée à la partie appelée via les entités P-CSCF et S-CSCF. Ce message contient un datagramme SDP qui indique pour chaque flux de média que l'UE appelant souhaite établir, un certain nombre de paramètres de média tels que : type de média, combinaison d'attributs de QoS, liste de codées capables d'être supportés pour cette session, ...etc. Les entités P-CSCF et S-CSCF associées à la partie appelante puis à la partie appelée effectuent alors un contrôle de service (selon des critères propres au réseau) sur ces paramètres. La partie appelée détermine alors entre autre sa propre liste de codées capables d'être supportés pour cette session, puis une liste de codées capables d'être supportés en commun par les deux parties, appelante et appelée, et retourne alors cette dernière liste à la partie appelante. La partie appelante détermine alors quels flux de média devraient être utilisés pour cette session, et quels codées, dans cette liste, devraient être utilisés pour cette session. L'étape S3 correspond essentiellement à une fin d'établissement de session, et comporte une étape d'allocation de ressource, à partir des caractéristiques de flux de média (en terme d'attributs de QoS, de codée négocié, etc) ainsi déterminées dans l'étape S2.
L'étape S3 utilise aussi une procédure d'activation de contexte PDP, appelée aussi procédure d'activation de contexte PDP secondaire (pour la distinguer de la procédure d'activation de contexte primaire utilisée dans l'étape SI ). L'étape S3 est semblable à l'étape SI , à ceci près que les paramètres de porteuse UMTS à établir correspondent maintenant aux besoins déterminés dans l'étape S2. L'étape S3 comporte elle-même des étapes qui sont semblables à celles de la l'étape SI , et qui pour cette raison ne seront pas re-décrites.
L'étape S3 comporte ainsi l'établissement d'un RAB pour ce contexte PDP secondaire. Lorsque ce RAB est établi, le RAN effectue un contrôle d'admission et accepte ou rejette l'appel.
On rappelle par ailleurs que, d'une manière générale, dans ces systèmes, il est nécessaire de prévoir une gestion de la qualité de service (ou QoS, pour « Quality of Service ») de manière à satisfaire les besoins des utilisateurs, en tenant compte d'une différenciation des applications et des utilisateurs, et tout en utilisant aussi efficacement que possible les ressources de transmission disponibles. D'une manière générale, chaque service est défini par des paramètres ou attributs de qualité de service (tels que le débit binaire garanti, le délai de transfert, ...etc.), l'ensemble de ces paramètres ou attributs formant un profil de qualité de service. Pour le GPRS, la gestion de la qualité de service a fait l'objet d'améliorations entre les versions R97 et R99 de la norme.
Dans la version R97 de la norme, seuls des services non temps réel peuvent être offerts aux utilisateurs. Ainsi, dans le sens montant, la station mobile peut indiquer des paramètres de QoS quand elle requiert l'établissement d'un TBF (pour « Temporary Block Flow ») dans le sens montant, en utilisant une procédure d'accès dite en deux phases. Dans le sens descendant, chaque LLC PDU reçue du SGSN contient un élément d'information appelé « QoS Profile Information Elément », donnant des informations limitées sur la qualité de service. Ces paramètres peuvent être utilisés par le BSS pour effectuer dans une certaine mesure une différenciation de services.
Dans la version R99 de la norme, une nouvelle procédure, ou procédure de création de « BSS Packet Flow Context» a été introduite, définie notamment dans les spécifications 3GPP TS 23.060 et 3GPP TS 08.18. Cette procédure autorise la négociation entre le SGSN et le BSS de tous les paramètres de QoS à offrir pour le transfert de toute LLC- PDU se rapportant au PFC (« Packet Flow Context ») ainsi créé. Le SGSN peut aggréger le transfert de LLC-PDUs correspondant à plusieurs contextes PDP donnés (ou « PDP Context », où PDP est utilisé pour « Packet Data Protocol ») dans un même PFC. Ceci est possible si les PDP Contexts aggrégés ont des contraintes de qualité de service proches. Les paramètres de QoS ainsi négociés sont ceux définis dans la version R99 et contiennent beaucoup plus d'informations que le profil de QoS défini dans la version R97. Ils contiennent en particulier toutes les variables nécessaires pour la définition d'un service temps réel.
Le contexte de PDP (ou « PDP context ») créé lors de l'établissement d'une session de données contient les informations nécessaires au transfert des données entre MS et GGSN (informations de routage, profil de QoS, ...etc.). Lorsqu'il active un contexte PDP, si la fonctionnalité PFC est implémentée dans le BSS et le SGSN, ce dernier peut requérir des paramètres de QoS du BSS qui peut négocier tout ou partie de ces paramètres en fonction de sa charge et de ses capacités. Ceci signifie que les données associées à un contexte PDP et donc à une QoS donnée sont bien identifiées non seulement dans le cœur de réseau CN mais aussi dans le réseau d'accès radio RAN. Ceci permet d'assurer que la QoS offerte pour le contexte PDP est négociée entre tous les nœuds de réseau, et il devient ainsi possible de garantir certains attributs de qualité de service. Il est ainsi possible d'obtenir qu'un débit binaire garanti ou un délai de transfert maximum soit offert, ce qui permet d'offrir des services temps réel.
Pour supporter des applications temps réel il est nécessaire que le BSS soit capable d'offrir le débit requis et aussi de transférer les LLC PDUs reçues dans les limites du délai de transfert maximum. Pour cela, il est nécessaire qu'il y ait aussi peu que possible de mise en file d'attente dans le BSS (on rappelle que la mise en file d'attente est propre au transfert utilisé dans les systèmes en mode paquet), et que les interruptions de transfert (dues notamment aux re-sélections de cellule, comme rappelé précédemment) soient aussi courtes que possible. Ceci requiert que le BSS connaisse toujours les spécifications de QoS pour le transfert de telles données, ou en d'autres termes qu'il dispose d'un contexte contenant des informations de profil de QoS associées.
Selon la procédure de création de « BSS Packet Flow Context», telle que spécifiée notamment dans le document 3GPP TS 23.060, le SGSN peut à tout moment requérir la création d'un contexte appelé « BSS Packet Flow Context » (ou PFC), notamment lors de l'activation d'un contexte PDP.
La figure 6 est un schéma destiné à illustrer un exemple de mise en œuvre d'un procédé suivant l'invention.
On notera que la présente invention couvre aussi bien le cas d'un appel reçu par la station mobile (ou « MT Call », pour « Mobile Terminating Call ») que le cas d'un appel émis par la station mobile (ou « MO Call », pour « Mobile Originating Call ») à travers le domaine paquet (ou « PS domain »). Une étape dans ces différents scénarios est l'établissement d'un canal dédié, sur création d'un PFC. Les spécifications 3GPP concernant l'IMS (23.228 et 24.228) définissent les différents flux pour l'établissement d'appel, et le but n'est pas ici de les rappeler. Dans tous les scénarios, une étape importante qui constitue plus particulièrement un des objets de la présente invention est l'étape de réservation de ressources. Dans le cas d'établissement de session MO, ceci se produit entre l'envoi des messages « Final SDP » et « Resource Réservation successful» . Dans le cas d'établissement de session MT, ceci se produit après que le message « Final SDP » ait été reçu de la partie appelante.
On suppose qu'un contexte PDP pour la signalisation SIP est établi et que le MS est dans le mode « Packet Idle Mode », lorsqu'une réservation de ressources est effectuée (si un TBF est en cours, alors le premier établissement de TBF ne sera pas effectué) .
Les étapes suivantes peuvent être mises en œuvre:
(1 ) Le MS déclenche une activation de contexte PDP secondaire pour le flux de média, dont les paramètres de QoS ont été négociés au niveau SIP. Pour cela, le
MS requiert un TBF montant (ou UL TBF, pour « Uplink TBF ») sur des canaux partagés.
(2) Lorsque le SGSN reçoit le message «ACTIVATE PDP CONTEXT REQUEST du MS, il créé le contexte PDP dans le SGSN et envoie alors un message CREATE BSS PFC sur l'interface Gb, afin de demander au BSS de réserver les ressources radio nécessaires pour le flux de média temps-réel.
(3) La QoS requise indique des caractéristiques de temps-réel. Il est ici proposé d'autoriser le BSS à allouer des ressources dédiées. Deux méthodes ou procédures sont proposées dans le cas où le BSS peut allouer de telles ressources en correspondance avec la QoS requise: ré-utiliser autant que possible les techniques existantes en envoyant un « paging » au MS, ou introduire un nouveau message d'allocation. On peut noter qu'à ce stade le MS est nécessairement dans l'état GMM READY puisqu'une LLC PDU dans le sens montant vient d'être envoyée, contenant le message ACTIVATE PDP CONTEXT REQUEST. (3a) Dans une première procédure, le BSS génère un « paging » vers le MS.
Dans l'état actuel de la norme pour le mode A /Gb, un MS peut recevoir un « CS paging » (ou « paging » pour services en mode circuit) seulement si ce « CS paging » est reçu du MSC. Il est ici proposé que le BSS génère un « paging » pour des services temps-réel après avoir reçu une requête du SGSN. Suivant l'état radio du MS, le message de « paging » peut être envoyé soit sur des canaux de contrôle communs soit sur le PACCH d'un TBF en cours. Ceci serait similaire à un « CS paging », avec l'exception qu'une indication serait présente pour indiquer que ce « paging » vient du domaine PS (« Packet Switched ») ou mode paquet. Si un ou plusieurs TBF étaient en cours, le MS retournera aux canaux de contrôle communs et initiera une procédure d'accès aléatoire (« random access ») en demandant des ressources dédiées (une autre option consisterait en une amélioration des procédures de DTM (« Dual Transfer Mode ») de manière à autoriser le MS à initier un accès dédié à travers le PACCH d'un TBF en cours). Le BSS allouera alors des ressources dédiées et le MS établira le lien de signalisation de couche 2.
Il est aussi proposé de demander à la station mobile MS d'envoyer un message GPRS INFORMATION contenant l'identifiant TLLI (« Temporary Logical Link Identifier ») propre à la station mobile MS. Ce message peut aussi contenir une trame LLC vide superposée (« piggybacked » en anglais) au message SABM. Le TLLI sera renvoyé au BSS, de sorte que le BSS peut associer la connexion nouvellement établie à la requête reçue dans le message CREATE BSS PFC. Dans le cas où les ressources allouées ne correspondent pas à la QoS requise, un « handover » intracellulaire peut être effectué pour allouer des ressources en correspondance avec la requête reçue du SGSN (ou en correspondance avec la QoS négociée avec le SGSN) si de telles ressources sont disponibles. Le message GPRS INFORMATION peut être envoyé sur le canal dédié DCCH (« Dedicated Control Channel ») une fois établi. On note que tout autre message contenant le TLLI du MS peut être utilisé.
(3b) Dans une seconde procédure, on alloue directement au MS des resources dédiées : un nouveau message pourrait être introduit, évitant le besoin d'avoir à envoyer un « paging » au MS. Le BSS allouerait alors directement les ressources dédiées, à travers un nouveau message envoyé sur les canaux de contrôle communs (MS dans le mode « Packet Idle Mode ») ou sur le PACCH d'un TBF en cors (MS dans le mode « Packet Transfer Mode »). Le MS activera alors les nouvelles ressources (éventuellement en basculant vers le mode « RR Dual Transfer Mode » si un ou plsieurs TBF étaient en cours) et établira le lien de signalisation de couche 2. Comme dans la première procédure, le MS enverra un message GPRS INFORMATION contenant le TLLI, qui sera renvoyé au BSS . Dans ce cas, les ressources allouées devraient être en correspondance avec la QoS requise. (4) Le BSS envoie alors un acquittement au SGSN pour la création du PFC. Il est à noter que dans le cas où le BSS ne pourrait allouer des ressources permettant de réaliser la QoS requise, il peut tout d'abord essayer de négocier les paramètres de QoS, et si la négociation réussit, il peut alors effectuer l'établissement des canaux dédiés.
(5) L'activation de contexte PDP est alors terminée (à travers l'établissement d'un TBF, ou en utilisant le message GPRS INFORMATION, ou en utilisant un TBF existant s'il est toujours en cours),
(6) L'établissement de l'appel peut alors être terminé au niveau SIP.
Lorsque la session a commencé, les PDU temps-réel sont routées comme suit: dans le sens réseau vers MS : GGSN -> SGSN (Interface « Gn »), SGSN ->BSC (interface « Gb ») , BSC- BTS (Interface Abis), BTS -» MS
(Interface radio) dans le sens MS vers réseau : MS -> BTS (Interface radio), BTS -> BSC
(Interface « Abis »), BSC - SGSN (Interface « Gb »), SGSN •» GGSN
(Interface « Gn ») Sur les interfaces « Gb » et « Gn » les PDUs sont routées comme des paquets. Sur les interfaces « Abis » et radio, les PDUs sont transportées sur des canaux dédiés.
Pendant le flux temps réel, les mesures radio reportées sont envoyés du MS au BSS sur le SACCH existant. Sur la base de ces mesures radio reportées, le BSS peut effectuer des « handovers » en utilisant les mécanismes existants. Sur la figure 6 : l'étape 61 indique que l'établissement d'un appel est en cours pour un flux de média temps réel, le « Final SDP » vient d'être envoyé (dans le cas MO) ou reçu (dans le cas MT), - l'étape 62 indique qu"un contexte PDP secondaire est créé dans le
SGSN, l'étape 63 indique que le BSS a reçu une requête « PFC Création Request » pour un flux temps réel, il établit des ressources dédiées, l'étape 64 indique que le MS active les ressources dédiées allouées, - l'étape 65 indique qu'un fonctionnement en multi-trame est maintenant établi, la contention est résolue, et le BSS connaît le TLLI de la nouvelle connexion. Un « handover » est effectué si nécessaire, l'étape 66 indique que l'établissement d'appel SIP peut alors se produire, l'option correspondant à la première procédure indiquée plus haut a été notée 67 - l'option correspondant à la seconde procédure indiquée plus haut a été notée 68. Les différents messages notés sur la figure 6 : (P)RACH, PACKET UPUNK ASSIGNMENT, ACTIVATE PDP CONTEXT REQUEST (secondary PDP context), CREATE BSS PFC, CS PAGING (from the PS domain), IMMEDIATE ASSIGNMENT, SABM + GPRS INFORMATION, UA + GPRS INFORMATION, CREATE BSS PFC ACK , ACTIVATE PDP CONTEXT ACCEPT, ont été soit rappelés soit définis précédemment. Eventuellement, pour plus d'informations sur les messages ou procédures existants on pourra se reporter aux spécifications correspondantes, pour ces systèmes).
On notera que l'exemple ainsi décrit ne constitue qu'un des exemples possibles de mise en œuvre de l'invention. On comprendra qu'il n'est pas possible de décrire ici tous les exemples de mise en œuvre possibles, et que la présente invention est bien sûr d'application générale, et n'est pas limitée à cet exemple particulier.
Un des avantages de l'invention est que les procédures ou protocoles existants sont ré-utilisés. Notamment, il n'y a pas besoin d'introduire une nouvelle combinaison de canal, ni un « handover » de TBF. Les impacts sur une station mobile selon la version R99 de la norme supportant le mode DTM (« Dual Transfer Mode ») sont réduits à un minimum (le contexte PDP pour lequel un canal dédié est alloué doit être indiqué à la station mobile). Il n'y a pas besoin de définir une nouvelle couche de protocole au-dessus de la couche RLC/MAC puisque la couche RR au-dessus de
LAPDm peut être ré-utilisée. Toute la signalisation peut être effectuée à travers les canaux existants SACCH et FACCH. Ceci n'empêche pas d'améliorer les procédures
DTM existantes pour supporter des « handovers » simultanés de trafic temps réel transporté dans des canaux dédiés et de trafic non temps réel transporté dans des canaux partagés. Notamment l'invention permet d'introduire un support pour des services IMS dans le mode « A/Gb » du réseau GERAN à un coût minimum.

Claims

REVENDICATIONS
1 . Procédé pour supporter du trafic temps réel dans un système de radiocommunications mobiles comportant un réseau d'accès radio et un cœur de réseau, procédé dans lequel du trafic en temps réel supporté en mode paquet dans le coeur de réseau est supporté dans le réseau d'accès radio au moyen d'une allocation de canaux dédiés.
2. Procédé selon la revendication 1 , dans lequel ladite allocation de canaux dédiés est effectuée à la création d'un contexte de flux paquet (PFC).
3. Procédé selon la revendication 2, dans lequel ledit contexte de flux paquet est crée dans le réseau d'accès radio.
4. Procédé selon la revendication 3, dans lequel ledit contexte de flux paquet contient des paramètres de QoS à offrir par le réseau d'accès radio et négociés avec le cœur de réseau.
5. Procédé selon l'une des revendications 1 à 4, dans lequel ledit trafic temps réel correspond à au moins un flux de média d'une session multimédia.
6. Procédé selon l'une des revendications 1 à 5, dans lequel ladite allocation de canaux dédiés utilise une procédure d'allocation comportant un « paging » suivi d'un accès au réseau.
7. Procédé selon l'une des revendications 1 à 5, dans lequel ladite allocation de canaux dédiés utilise une procédure d'allocation directe.
8. Procédé selon l'une des revendications 1 à 7, dans lequel : une station mobile à laquelle des canaux dédiés ont ainsi été alloués transmet au réseau des informations relatives à son identité, sur la base de ces informations, le réseau associe un contexte de flux paquet à cette station mobile, et , le cas échéant, une ré-allocation de canaux dédiés est effectuée en vue de satisfaire la qualité de service requise pour cette station mobile.
9. Equipement de réseau d'accès radio pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.
10. Equipement de cœur de réseau pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.
1 1 . Station mobile pour système de radiocommunications mobiles, comportant des moyens pour mettre en œuvre un procédé selon l'une des revendications 1 à 8.
PCT/FR2003/001738 2002-06-11 2003-06-11 Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles WO2003105505A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP03757136A EP1516500A1 (fr) 2002-06-11 2003-06-11 Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles
US10/517,370 US20050169207A1 (en) 2002-06-11 2003-06-11 Method for supporting real time traffic in a mobile radio communications system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0207173A FR2840758B1 (fr) 2002-06-11 2002-06-11 Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles
FR02/07173 2002-06-11

Publications (1)

Publication Number Publication Date
WO2003105505A1 true WO2003105505A1 (fr) 2003-12-18

Family

ID=29559138

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/001738 WO2003105505A1 (fr) 2002-06-11 2003-06-11 Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles

Country Status (5)

Country Link
US (1) US20050169207A1 (fr)
EP (1) EP1516500A1 (fr)
CN (1) CN1659906A (fr)
FR (1) FR2840758B1 (fr)
WO (1) WO2003105505A1 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060140113A1 (en) * 2004-12-29 2006-06-29 Anderlind Erik E Method for efficiently transmitting communications in a system supporting dedicated and shared communication channels
CN101176357A (zh) * 2005-05-13 2008-05-07 阿尔卡特朗讯公司 用于uma unc应用的分组域的改进的核心网接口
US7424294B2 (en) * 2005-08-31 2008-09-09 Motorola, Inc. Method and system for switching a mobile device in a mobile network
DE102005042536A1 (de) * 2005-09-07 2007-03-15 Siemens Ag Verfahren zum Betreiben einer Funk-Kommunikation in einem Multi-Funkverbindungs-Kommunikationsssystem
US20070064709A1 (en) * 2005-09-20 2007-03-22 Telefonaktiebolaget Lm Ericsson (Publ) Minimized setup time for IMS multimedia telephony using pre provisioned resources reserve at invite
US20070064710A1 (en) * 2005-09-20 2007-03-22 Telefonaktiebolaget Lm Ericsson (Publ) Minimized setup time for IMS multimedia telephony using pre provisioned resources reserve according to most demanding codec
US20070201430A1 (en) * 2005-12-29 2007-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Implicit secondary PDP context activation method
JP2009535980A (ja) * 2006-05-03 2009-10-01 インターデイジタル テクノロジー コーポレーション 効率的なパケットデータプロトコルコンテキストアクティブ化プロシージャを介して複数のサービスベアラをアクティブ化するためのワイヤレス通信方法及びシステム
US20070258427A1 (en) * 2006-05-03 2007-11-08 Interdigital Technology Corporation Wireless communication method and system for activating multiple service bearers via efficient packet data protocol context activation procedures
US7633903B2 (en) * 2006-05-10 2009-12-15 Telefonaktiebolaget L M Ericsson (Publ) Packet data support node and method of activating packet flow contexts during handover
US7848287B2 (en) * 2006-05-16 2010-12-07 Telefonaktiebolaget Lm Ericsson Bi-directional RLC non-persistent mode for low delay services
US20080026755A1 (en) * 2006-07-26 2008-01-31 Motorola, Inc. Method and system for establishing a multiple transfer mode session
WO2008084316A1 (fr) * 2007-01-08 2008-07-17 Nokia Corporation Procédé pour un service par commutation de circuit rapide permettant un transfert à partir de réseaux à commutation par paquet uniquement
JP5227403B2 (ja) * 2007-08-14 2013-07-03 テレフオンアクチーボラゲット エル エム エリクソン（パブル） コーデックのネゴシエーションおよび選定における、またはそれらに関する改善
GB2452698B (en) 2007-08-20 2010-02-24 Ipwireless Inc Apparatus and method for signaling in a wireless communication system
US9313769B2 (en) * 2008-01-14 2016-04-12 Qualcomm Incorporated Wireless communication paging and registration utilizing multiple types of node identifiers
KR20140046076A (ko) * 2008-03-21 2014-04-17 인터디지탈 패튼 홀딩스, 인크 패킷 교환 도메인으로부터 회선 교환 도메인으로의 폴백 방법 및 장치
KR101650608B1 (ko) 2009-10-30 2016-08-23 인터디지탈 패튼 홀딩스, 인크 무선 통신을 위한 시그널링
JP5465025B2 (ja) * 2010-01-27 2014-04-09 Ｎｅｃトーキン株式会社 導電性高分子懸濁液およびその製造方法、導電性高分子材料、固体電解コンデンサおよびその製造方法
CN102685814B (zh) * 2011-03-16 2016-12-21 上海无线通信研究中心 Lte网络中小区间移动重选参数的协商方法
GB2494153B (en) 2011-08-31 2018-11-28 Metaswitch Networks Ltd Selection of codecs
CN104244445A (zh) * 2013-06-13 2014-12-24 华为技术有限公司 数据包传输方法、接入点及无线通信系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5533019A (en) * 1994-01-31 1996-07-02 Motorola, Inc. Packet data in an analog cellular radiotelephone system
WO1999011032A2 (fr) * 1997-08-25 1999-03-04 Nokia Networks Oy Procede de transmission de donnees et systeme de stations de base
WO2001015468A1 (fr) * 1999-08-23 2001-03-01 Motorola Inc. Systeme et procede de selection de domaine
FR2803973A1 (fr) * 2000-01-17 2001-07-20 Sagem Reseau de radiocommunication a transmission par paquets adapte a communiquer avec un terminal mobile fonctionnant en mode circuit
US20010010687A1 (en) * 2000-01-25 2001-08-02 Hyundai Electronics Industries Co., Ltd. Method for allocating dedicated channel for transmitting packet in CDMA media access control (MAC) layer control unit
EP1161104A1 (fr) * 2000-06-02 2001-12-05 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Réseau de controle d appels,serveur de controle d accès et procédé de controle d appels

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI108601B (fi) * 1999-01-05 2002-02-15 Nokia Corp QoS-kartoitustiedon välitys pakettiradioverkossa
FI114768B (fi) * 1999-03-11 2004-12-15 Nokia Corp Parannettu menetelmä ja järjestely tiedon siirtämiseksi pakettiradiopalvelussa
US6490451B1 (en) * 1999-12-17 2002-12-03 Nortel Networks Limited System and method for providing packet-switched telephony
CA2370664C (fr) * 2000-02-18 2009-02-03 Nokia Networks Oy Systeme de telecommunications
US6898194B1 (en) * 2000-05-09 2005-05-24 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for fast access to an uplink channel in a mobile communications network
FI110738B (fi) * 2000-05-22 2003-03-14 Nokia Corp Datansiirto tilaajapäätelaitteen paikantamispalvelun toteuttavassa pakettikytkentäisessä radiojärjestelmässä
US6889050B1 (en) * 2000-11-22 2005-05-03 Telefonaktiebolaget Lm Ericsson (Publ) Variable transmission rate services in a radio access network
FI112138B (fi) * 2001-02-09 2003-10-31 Nokia Corp Kehittynyt menetelmä ja järjestely tiedon siirtämiseksi pakettiradiopalvelussa
ATE350868T1 (de) * 2001-05-10 2007-01-15 Nortel Networks Ltd System und verfahren zur umleitung von kommunikation zwischen mobiltelekommunikationsnetzen mit unterschiedlichen funkzugangstechnologien
US7145919B2 (en) * 2001-06-01 2006-12-05 Telefonaktienbolaget Lm Ericsson (Publ) Method and apparatus for transporting different classes of data bits in a payload over a radio interface
DE10131561A1 (de) * 2001-06-29 2003-01-16 Nokia Corp Verfahren zur Übertragung von Anwendungspaketdaten
US7200125B2 (en) * 2001-10-12 2007-04-03 Nortel Networks Limited Method and apparatus for differentiated communications in a wireless network
DE60129054T2 (de) * 2001-12-04 2008-02-21 Nokia Siemens Networks Oy Funkbetriebsmittelverwaltung von paketdaten auf portnummerbasis

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5533019A (en) * 1994-01-31 1996-07-02 Motorola, Inc. Packet data in an analog cellular radiotelephone system
WO1999011032A2 (fr) * 1997-08-25 1999-03-04 Nokia Networks Oy Procede de transmission de donnees et systeme de stations de base
WO2001015468A1 (fr) * 1999-08-23 2001-03-01 Motorola Inc. Systeme et procede de selection de domaine
FR2803973A1 (fr) * 2000-01-17 2001-07-20 Sagem Reseau de radiocommunication a transmission par paquets adapte a communiquer avec un terminal mobile fonctionnant en mode circuit
US20010010687A1 (en) * 2000-01-25 2001-08-02 Hyundai Electronics Industries Co., Ltd. Method for allocating dedicated channel for transmitting packet in CDMA media access control (MAC) layer control unit
EP1161104A1 (fr) * 2000-06-02 2001-12-05 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Réseau de controle d appels,serveur de controle d accès et procédé de controle d appels

Also Published As

Publication number Publication date
EP1516500A1 (fr) 2005-03-23
US20050169207A1 (en) 2005-08-04
FR2840758A1 (fr) 2003-12-12
FR2840758B1 (fr) 2004-11-26
CN1659906A (zh) 2005-08-24

Similar Documents

Publication Publication Date Title
WO2003105505A1 (fr) Procede pour supporter du trafic temps reel dans un systeme de radiocommunications mobiles
EP1273134B1 (fr) Technique d'etablissement d'appels dans un reseau mobile a protocole internet
EP1226683B1 (fr) Etablissement d'une session de communicatons presentant une qualité de service dans une système de communications
ES2414874T3 (es) Un procedimiento y una disposición para el establecimiento de una sesión de comunicaciones para multimedia
EP1999910B1 (fr) Configuration de la qualité de service d'une télécommunication sans fil
KR100879811B1 (ko) 이동전화가 발신하는 호출들에서 안내들을 제공하는 기술
FR2822320A1 (fr) Procede pour le controle de session d'appel multimedia dans un systeme cellulaire de radiocommunications mobiles
JP4763800B2 (ja) マルチメディア通信セッションを確立するための方法および装置
EP1685682B1 (fr) Indication de l'interruption du debit de services par le controle de reseau suivant une fonction de prise de decision de principe
CA2598959C (fr) Changement de service introduit sur le reseau, d'un mode parole a un mode multimedia
US7532613B1 (en) Establishing a communications session having a quality of service in a communications system
TWI261472B (en) Sessions in a communication system
US7787884B2 (en) Method for optimising quality of service in the packet-switched domainn of a mobile communication system
WO2003075594A1 (fr) Procede pour ameliorer la gestion de la qualite de service dans un systeme cellulaire de radiocommunications mobiles en mode paquet
KR20050077839A (ko) 이동통신 시스템에서 푸시투토크 서비스 제공 방법
KR101119316B1 (ko) 아이피 멀티미디어 서브시스템을 통한 푸쉬-투-토크 오버셀룰러 서비스에서 미리 설정된 세션의 서비스 품질 설정방법
JP2007166649A (ja) ２層通信ネットワークにおける接続解除

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 20038134403

Country of ref document: CN

Ref document number: 10517370

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2003757136

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2003757136

Country of ref document: EP