Patent Application
20050265382
The present invention relates in general to providing control information for a communications protocol. In particular the invention relates to providing control information for a protocol used in a communications device.
A communication system can be seen as a facility that enables communication sessions between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may comprise, for example, communication of voice, data, multimedia and so on. Communication systems providing wireless communication for communications devices, including various user equipment, are known. An example of the wireless systems is the public land mobile network (PLMN). Another example is the wireless local area network (WLAN).
A PLMN is typically a cellular system wherein a base transceiver station (BTS) or similar access entity serves user equipment (UE) such as mobile stations (MS) via a wireless interface between these entities. The operation of the apparatus required for the communication can be controlled by one or several control entities. The various control entities may be interconnected. One or more gateway nodes may also be provided for connecting the cellular network to other networks, such as to another cellular system or to a public switched telephone network (PSTN) and/or other communication networks such as an IP (Internet Protocol) and/or other packet switched data networks.
A cellular network can thus provide access to various services and applications provided by the cellular network or by entities or networks external to the cellular network. The same is true also for other wireless networks connected to further networks. There are proposals for architectures for providing services in an access-network independent manner. As an example, this means providing conference call facilities, can be used by any communications device having certain defined capabilities and accessing the conference call facilities via any access network.
One proposal for providing services independently of the specific access network used by a communications device is the IP Multimedia Subsystem (IMS), defined in the 3rd Generation partnership project 3GPP specifications. The IMS services can be accessed via any access network providing IP connectivity. The General Packet Radio Service (GRPS) relating to the Global System for Mobile Communications (GSM) and the Universal Mobile Telecommunications System (UMTS) are two examples of an IP Connectivity Access Network (ICAN) for IMS.
The IMS, as any communication system, defines various entities for controlling service subscriptions and for providing services to users. In the IMS, these entities are implemented as servers in a network. In order to be able to request for a service from a communication system a user typically needs to have a subscription to the service and needs to be registered in the system in a serving control entity. In the IMS, information about the subscribers (subscribers' profiles) is stored in a home subscriber server (HSS) and the serving control entity is a Serving Call Service Control Function (S-CSCF) entity. A user may register to the serving control entity via an access entity of the communication system. As mentioned above, the IMS is access network independent, so it is sufficient that the access network provides IP connectivity.
In addition to the serving control entity, the user may need to be associated with a proxy control entity. In the IMS, the proxy control entity is the P-CSCF. The proxy entity is assigned to an area within which the user has roamed. For a more general case, when a user accesses the network through an arbitrary type of access network it can be assumed that the access network assigns a proxy control entity for controlling the accessed services from that network point of view, e.g. for bandwidth management.
In the IMS, a call state control function (CSCF) entity may provide functions such as serving call state control (S-CSCF), proxy call state control (P-CSCF), and interrogating call state control (I-CSCF). Control functions may also be provided by entities such as a home subscriber server (HSS) and various application servers.
The communication between the user equipment (communications device) and elements of a communication network is typically based on an appropriate communication protocol or on a set of appropriate communication protocols. A communication system furthermore typically operates in accordance with a given standard or specification which sets out what the various elements of the system are permitted to do and how that should be achieved. Communication protocols and/or parameters which shall be used for a given connection may also be defined. In other words, a specific set of “rules” on which the communication can be based needs to be defined to enable communication by means of the system.
A communications protocol typically defines messages or message sequences relating to various actions and also default actions if, for example, a requested action cannot be carried out. A protocol typically has also various specified time limits for receiving responses to sent messages. If a response is delayed, the protocol typically does not function properly. There may be need to send a message relating to a certain action repetitiously. In a worst case, the requested action is not carried out at all.
One of the control protocols used in the IMS is the Session Initiation Protocol (SIP). SIP is a protocol specified in the Request for Comments RFC 3261 supplied to the Internet Engineering Task Force (IETF). Various timers are specified for SIP in RFC 3261, mainly in Section 17. Annex A of RFC 3261 lists timer values for SIP.
In connection with the IMS, the session initiation protocol is used, for example, for registering to the S-CSCF and for setting up sessions. It shall be appreciated that the term “session” used in this document refers to any communication a user may have such as to a call, data (e.g. web browsing) or multimedia communication and so on. Regarding the delays in receiving a response to a certain SIP message in connection with the IMS, a registration to a S-CSCF may fail or a requested session may not be established.
It has been noted that the SIP timer values specified in RFC 3261 are not necessary long enough for using the IMS and UMTS. This is because of the signaling delays caused, for example, by the air interface in the UMTS. To overcome this problem, longer timer values are specified in Section 7.7 and Table 7.5 of the 3GPP specification TS 24.229, version 5.6.0 Release 5. The 3GPP specification defines first timer values for use between network elements, second timer values for use in user equipment (or, more generally, in a communications device), and third timer values for use in a P-CSCF towards the user equipment.
Timer values in an operator's core network elements should be set according to the values defined in corresponding standards, for example, in the 3GPP standards. The operator can set the timer values using the management system of the network. However, delays in the network can be longer than recommended in standards due to, for example, the size of the network, implementation of the network (different suppliers), the structure and complexity of the network. Therefore an operator may want to use different (typically longer) timer values than specified in standards to guarantee better call success rate for the end users. Timer values in communications devices, such as in mobile phones, are set by the vendor during the manufacturing phase of the terminal. Later, a reseller could modify the values before selling the terminal to an end user. The end user is normally not aware of these timers at all. However, the problem arises when it is not known in which network the terminal will be used, and thus, the correct timer values cannot be configured in advance. Hence, the timer values in the terminal might be too short if the delays in operator's access and core networks are longer than recommended in standards.
There is furthermore at least one problem relating to specifying different timer values for SIP in connection with the IMS and UMTS than for SIP in general. As a communications device may have capabilities to access the IMS via a number of access networks or to use SIP for other purposes than for the IMS, the communications device needs to be able to determine and use correct timer values for ensuring successful control functionality when using SIP.
There are thus problems relating to determining correct SIP timer values for SIP protocol or other control protocols and to take the timer values into use in a communications device.
It shall be appreciated that although the above discussed problems relate to the IMS in third generation communication systems, similar disadvantages may be associated with other systems as well and thus the description is not limited to these examples.
It is an aim of embodiments of the present invention to address one or more of the problems discussed above.
A first aspect of the invention provides a method for providing control information for a protocol, said method comprising
A second aspect of the invention provides a communications device comprising
A third aspect of the invention provides a communications system comprising
A fourth aspect of the invention provides a network element for a communications system, said network element comprising
A fifth aspect of the invention provides a network element for a communications system, said network element comprising
Embodiments of the present invention will now be described by way of example only with reference to the accompanying drawings, in which:
A user information storage entity may also be provided for storing information associated with the subscription of the respective user. The user information storage entity may locate in a server of the home network of the subscription. Such subscriber information storage entities may be called by different terms in different communication systems, and in the IMS the subscriber information storage is called a Home Subscriber Server (HSS).
The session initiation protocol SIP is used for controlling sessions in the IMS. At least the following entities thus use SIP: the communications device UE, the controlling entity S-CSCF and the proxying entity P-CSCF. The SIP architecture contains, for example, a SIP client, a SIP server, a SIP proxy and a User Agent (UA). A SIP client is any network element that sends SIP requests and receives SIP responses. A SIP server is a network element that receives SIP requests in order to service them and sends back SIP responses to those requests. A SIP proxy is an intermediary entity that acts as both a SIP server and a SIP client for the purpose of making requests on behalf of other SIP clients. A SIP proxy server primarily plays the role of routing. A User Agent is a logical entity that can act as both a user agent client (UAC) and user agent server (UAS). A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction.
Referring to the IMS, the communications device using the IMS services acts in general as a SIP user agent. The proxy entity P-CSCF acts in general as a SIP proxy, but in some cases also as a SIP User Agent. The controlling entity S-CSCF acts in general as a SIP proxy, but has also some capabilities of a SIP registrar and accepts registering requests. A more detailed description of the capabilities of the communications device (user equipment), S-CSCF and P-CSCF can be found in the 3GPP specification TS 24.229, version 5.6.0, Release 5.
The SIP layer 205, in turn, comprises four sublayers. The lowest sublayer is the syntax/encoding layer 251, which relates to SIP message structures and to encoding of SIP protocol messages for providing payload information to the transmission protocol layer 204. The next sublayer is the transport layer 252, which defines how a SIP client sends requests and receives responses and how a SIP server receives requests and sends responses over the network.
The next sublayer is the transaction layer 253, and on top of the transaction layer 253 is a layer called the transaction user (TU) 254. User agents contain a transaction layer 253, as do stateful SIP proxies. Stateless SIP proxies do not contain a transaction layer 253. The transaction layer 253 has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular SIP request. Each of the SIP entities, except the stateless proxy, is a transaction user layer 254. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request.
Transactions are a fundamental component of the SIP. A transaction is a SIP request sent by SIP client transaction (using the transport layer) to a SIP server, along with all responses to that request sent from the SIP server back to the SIP client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions.
SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. Should there be no response to a given SIP message, a timer in the transaction layer 253 typically expires and causes the state machine to enter a new state.
A number of timers are specified for the SIP. Table 1 lists these timers, refers to relevant Sections of RFC 3261 and briefly explains the meaning of each timer. As Table 1 shows, timer T1 relates to round-trip-time estimate, and a default value is 500 ms. As mentioned above in connection with the discussion of the background art, longer timer values are specified in Section 7.7 and Table 7.5 of the 3GPP specification TS 24.229, version 5.6.0, Release 5. The 3GPP specification defines first timer values for use between network elements, second timer values for use in user equipment (or, more generally, in a communications device), and third timer values for use in a P-CSCF towards the user equipment.
It is clear to one skilled in the art that any packet data protocol may be applicable as an alternative to the Internet Protocol. As the IMS refers to IP, the IP is used here as an example of a packet data protocol. It is also clear to one skilled in the art that the IMS architecture is an example, and any service architecture having similar functionality and similar controlling and proxying functionality and/or entities may be used. Furthermore, the SIP protocol is here used as an example of a protocol having timers, specifically as an example of a control protocol.
The first access network 310 and the second access network 320 are typically wireless networks.
Even if both the first access network 310 and the second access network 320 were in accordance with the same standards and specifications, for example both are GPRS networks, the transmission delays may be quite different in these networks. The delays are typically, for example, due to the radio access network elements and packet switched network elements. In the GPRS example, the radio access network elements are the base stations and base station controllers and the packet switched network elements are the SGSN and the GGSN. Also on the size and load of the access network and those of the IP backbone network, for example, may affect the delays. Equally sized networks may have different delays due to the fact that the network elements have been manufactures by different vendors. A certain network may be usually very busy, whereas another network may usually have a very light load. Furthermore, it is possible that the delays are dependent on the location of the communications device within the coverage area of the access network.
When the communications device 301 is accessing a service provided by the application server AS 333 via the first access network 310 different SIP timer values may thus be applicable than when the communications device 301 is accessing the service via the second access network 320. As
It is appreciated that typically a network element, for example, a serving entity S-CSCF or a proxying entity P-CSCF, has a set of timer values that it uses for controlling all sessions. If a network element has session-specific timers or user-specific timers, these can be configured to have same values as those in a communications device whose session the network element is controlling. This configuration can be done, for example, using the normal configuration and management interfaces of a network.
It is possible to measure and determine delays relating to a certain network or to a certain part of a network for determining suitable timer values for the SIP timers. Similarly, if for example a delay relating to an IP backbone network are significant, the SIP timer values can be chosen so that they take these into account as well.
One specific example of a SIP protocol timer, which may need configuring, is the roundtrip timer, namely timer T1. The roundtrip timer is used in the INVITE transaction of the SIP protocol, discussed in Section 17.1.1.1 of the RFC 3261. The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE message, the server transaction sends responses, and the client transaction sends an ACK message. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms in accordance with the RFC 3261. As table 1 shows, many other timers scale with T1. This means that changing T1 adjusts the values of these other timers as well.
For controlling the SIP protocol, timer values are sent from the communications system to the communications device 301. The communications device 301 may be provided with functionality to receive configuration or control information from the communications network. One example of sending and receiving configuration or control information is the Over-the-Air (OTA) interface. Usually configuration or control information is provided by the home network (the communication system 300a in
In the first embodiment of the invention, the timer values suitable for use in the home network are sent to the communications device 401 of the user subscribing to the service. The timer values suitable for use with the home network are sent because the communications device 401 may have preset timer values in the user's communications device, which are different from the suitable timer values for the home network. Alternatively, the communications device 401 may lack any preset timer values. For sending the suitable timer values, the service subscription manager 410 may fetch timer values for the home network from an information store 420. The timer values may be stored, for example, in a suitable network element. The timer values for the control protocol, for example for SIP in connection with the IMS, are sent to the user's communications device 401 for example via a terminal manager 430.
The timer values may be sent by the terminal manager 430 using, for example, an Over-The-Air (OTA) interface or using SyncMI. The OTA interface refers to sending control information to a communications device using short messages (SMS). The OTA interface relates to client provisioning and device management, and it is specified by Open Mobile Alliance. In this case the user may need to explicitly accept the received timer values. The SyncML is based on a client-server solution, and the communications device 401 thus contains a client application, which may be able to receive and save the timer values without user interaction. It is appreciated that there may be many other possibilities to send the timer values to the communications device 401. It is furthermore appreciated that the timer values may be sent together with other control information. One example of such other control information is IMS parameters sent to a communications device 401 after the IMS subscription for enabling the user of the communications device to access IMS services.
The SIP timer values in use in the communications device 501 when the communications device enters the visited network 510 may be, for example, default SIP timer values in accordance with the relevant 3GPP standards. As a second example, the timer values may have been set by the home network of the user of the communications device 501 when the IMS service was subscribed to. The visited network 510 may use different SIP timer values. The communications device 501 and the proxy control entity P-CSCF 511 should employ same SIP timer values for making session initiation reliable and successful. Therefore the visited network may send information indicating at least one timer value to the communications device 501 of a roaming user.
The SIP timer values may be sent from the proxying control entity P-CSCF 511 to the communications device 501 after the 200 OK message 609.
With respect to
It is also appreciated that if, for example, a serving control entity S-CSCF 521 is triggering the sending of information indicating timer values, the timer values may be sent to the user irrespectively of whether the user is in the home network 520 or in a visited network 510. The timer values should, however, be values suitable for use in that network where the user currently is.
Further details relating to
The sending block 901 is responsible for sending information indicating at least one timer value for a protocol used in a communications device. Some examples of network elements, where the sending block 901 may be implemented, are a terminal manager 430, a proxying control entity P-CSCF 511 and a SGSN 712. The triggering block 902 is responsible for triggering sending of the timer values. It is possible that the triggering block 902 is implemented together with the sending block 901. Some examples of network elements, where the triggering functionality may be implemented, are a subscription manager 410, a serving control entity S-CSCF 521 (typically separately from the sending block 901), a proxying control entity P-CSCF 511 (typically together with the sending block 901), and a SGSN 712 (typically together with the sending block 901). The triggering block 902 can also be located somewhere in an operator's management interface, in particular in case the operator decides to configure the timer values of many or all the terminals connected in the network.
A configuring block 905 is responsible for configuring new timer values to relevant network elements. Examples of the relevant network elements are the proxying control entity P-CSCF for roaming users and the service control entity S-CSCF for users in their home network.
It is appreciated that blocks 903, 904 and 905 in
The timer configuring functionality 1020 may be arranged to store at least one previous value 1021 for the timers relating to the protocol, typically the previous set of timer values. Storing at least one previous timer value (a previous set of timer values) may be useful, for example, in the case where a roaming communications device enters a new network and the new network has no functionality for sending information indicating at least one timer value. If it is noticed, for example, by a repeated failure to register to the S-CSCF, that the latest set of timer values defined too strict timer values, the previous set of timer values may be taken into use. Alternatively, the timer configuring functionality 1020 may be arranged to store a default set of timer values. These default values may be used when the new access network does not send any information indicating timer values for the control protocol. A further option is that the timer configuring functionality 1020 is arranged to store two sets of default time values: a first set of timer values relating to the home network and a second set of timer values relating to a visited network. In this case, when the communications device enters a new network, the timer configuring functionality 1010 may be told whether the new network is the home network or a visited network and it may update the protocol timers accordingly.
It is appreciated that although in the detailed description above the session initiation protocol SIP is used as an example of a control protocol and the IMS is used as an example of service providing architecture, the invention is applicable with other protocols, control protocols and service architectures/frameworks.
It is appreciated that in the appended claims registration to a service framework refers to actions carried out between a communications device and relevant network entities of the service framework for enabling the communications device to access services of the service framework. The IMS is used above as a specific example of a service framework. The registration to the service framework may be carried out, for example, automatically upon a communications device entering a visited access network or entering the home access network.
It is appreciated that sending information indicating at least one timer value to a communications device for configuring a protocol in the communications device may be applicable also in other connections than in service frameworks such as the MS. For example, information indicating timer values may be sent to a communications device upon entering a visited access network, for example when the communications device roams in a visited cellular communications network.
It is furthermore appreciated that in the appended claims sending information indicating at least one timer value in connection with a certain procedure, for example in connection with registering to a service framework or with activating a packet data context, refers to sending said information as part of the procedure. Typically the information is sent using message(s) of the same protocol which is used for the procedure.
It is also appreciated that the communications device may be any communications device capable of communicating with a communications system and having the necessary functionality for accessing and using services. Examples of communications devices are user equipment, mobile telephones, mobile stations, personal digital assistants, laptop computers and the like. Furthermore, a communications device need not be a device directly used by human users.
Although preferred embodiments of the apparatus and method embodying the present invention have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20040742 | May 2004 | FI | national |
