[go: up one dir, main page]

EP1891821A2 - Procede et appareil de fourniture d'un service de telecommunications - Google Patents

Procede et appareil de fourniture d'un service de telecommunications

Info

Publication number
EP1891821A2
EP1891821A2 EP05752739A EP05752739A EP1891821A2 EP 1891821 A2 EP1891821 A2 EP 1891821A2 EP 05752739 A EP05752739 A EP 05752739A EP 05752739 A EP05752739 A EP 05752739A EP 1891821 A2 EP1891821 A2 EP 1891821A2
Authority
EP
European Patent Office
Prior art keywords
network
service
account
telecommunications
user terminal
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP05752739A
Other languages
German (de)
English (en)
Inventor
Alfredo Gonzalez Plaza
Luis Ramos Robles
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP1891821A2 publication Critical patent/EP1891821A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/062Pre-authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/068Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • H04W12/082Access security using revocation of authorisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • H04W12/084Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24Accounting or billing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20Transfer of user or subscriber data

Definitions

  • the present invention relates to telecommunications services provided from telecommunications networks to user terminals, and particularly to the provision of access to telecommunications services in interworking scenarios comprising a first telecommunications network, to which a user terminal is connected, and a second telecommunications network providing the telecommunications service to the user terminal through the first telecommunications network.
  • telecommunications network infrastructure comprising, not only the specific servers so as to provide the final telecommunications services to the user terminals (e.g. signaling handling servers, specific application servers, etc) , but also specific access servers arranged to provide access connection for said terminals to the rest of the telecommunications network (e.g. local exchanges, radio access servers, etc) as well as the rest of the access infrastructure (cables, antennae, etc) .
  • a main challenge for operators of telecommunications networks is to provide seamless telecommunications services to end users; namely, provide services without concern or limitation being imposed by the particular aspects of the particular telecommunications networks to which the eventual users might connect their terminals; thereby, allowing advantageously to develop telecommunications services which can be substantially independent of the particular access technologies .
  • interworking tools for achieving more homogeneous, and thus, interoperable communication frameworks, such as the extended usage of the Internet Protocol IP as a (inter) network protocol, as well as the wide use of protocol and media gateways for allowing interconnection of heterogeneous telecommunications networks, have helped to overcome some of the compatibility problems arising in earlier telecommunications networks, and have consequently allowed to devise and offer telecommunications services that, for example, can be served from the same service platform (e.g. one or more specific application servers) within the telecommunications network of a network operator to user terminals that are not necessarily connected to said telecommunications network, but that can be connected to another cooperating telecommunications network (s) instead, which may even belong to a different network operator.
  • service platform e.g. one or more specific application servers
  • new interworking scenarios involving at least two telecommunications networks are presently envisaged which goes beyond the mere provision of interconnection services for end user's terminals, like interconnection services providing voice communications between a terminal connected to cellular network (such as a Global System for Mobile communications network, GSM) and another terminal connected to a fixed network (such as a Public Switched Telephone Network, PSTN) .
  • These new interworking scenarios comprise a telecommunications network having the means to provide a telecommunications service to a user terminal (e.g. one or more specific service application servers devoted to provide one or more service) , and another telecommunications network to which a user terminal can be connected and through which the access to the telecommunications service may be provided.
  • a user terminal connected to a first telecommunications network may access a service provided from (i.e. by, or with the intervention of) a second telecommunications network.
  • IP Multimedia-System IMS IP Multimedia Services
  • IMS services IP Multimedia Services
  • Examples of telecommunications networks to which user terminals can attach so as get IP connectivity and then obtain access to the IMS services provided by a IMS are: a Local Area Network LAN, a Wireless LAN WLAN, a PSTN, or the General Packet Radio System GPRS of a cellular telecommunications network.
  • interworking scenarios of this or similar nature can also be envisaged in so far as they involve a first telecommunications network to which user terminals are connectable so as to access through it a service provided from a second telecommunications network.
  • telecommunications networks which are usually independent of the nature of the telecommunications services they can offer, which can range from mere bearer services for providing physical connection to a user terminal, so as to allow it to communicate with another user terminal or server, to more complex services such as: personalized information services (e.g. location-based services, stock market information), messaging services (e.g. short message services, multimedia services, voice messaging services, messaging format conversion) , services involving intelligent call processing, digital identity support for electronic commerce, etc.
  • personalized information services e.g. location-based services, stock market information
  • messaging services e.g. short message services, multimedia services, voice messaging services, messaging format conversion
  • services involving intelligent call processing e.g. short message services, multimedia services, voice messaging services, messaging format conversion
  • a common aspect is that the access to the services provided from a telecommunications network is usually subject to a previous subscription of a "service account" in said network.
  • This aspect uses to be common except in cases in which the nature of the service is such that it may given to anyone without restriction nor personalization criteria (e.g. the service is a general information service given without any kind of discrimination criteria based on the served user) .
  • a user wanting to access from a suitable user terminal to the telecommunications services provided from a telecommunications network of a network operator signs a business agreement with said operator, which is an administrative transaction that establishes a direct business relationship between them in virtue of which the user (also called “subscriber” from that moment) subscribes to a pre-paid or post-paid service account with said operator and, in some cases, can receive, among other, user credentials for authenticating him from a given terminal.
  • the signing of the business agreement can, in some cases, comprise merely the acquisition by the user of the necessary item(s) containing the corresponding user credentials (e.g.
  • the business agreement usually further comprises the provision from the subscriber of a payment account to which the costs of the serviced services are to be ascribed.
  • subscription data or “subscriber data”
  • subscriber data are usually managed by administration and maintenance procedures of the operator of said network, which normally comprise initial data provision in the relevant server (s) of said network upon subscription of the service account.
  • details related to the quantity, specific nature and storage details (e.g. if distributed or centralized) of the data related to a service account may vary according to the kind of telecommunications network and also according to the operator of said network.
  • a service account comprise the necessary static and dynamic data that are stored in relationship with a subscription and that may be required for service provision to the corresponding subscriber, such as: identification information (e.g.
  • this first common aspect uses to imply that the user may be required to subscribe service accounts in advance in all the telecommunications networks he might eventually use for accessing a telecommunications service provided by a certain telecommunications network.
  • a further common aspect is that, when service provision in a telecommunications network depends on the existence of the corresponding service account, authentication of user terminal according to the corresponding user credentials uses to be required in some cases ,- for example, whenever the user terminal may access a telecommunications network from different access points of said network (or even via another telecommunications network) , or whenever the user terminal may be used by different users and/or a personalized service (e.g. based on user subscription) is intended to be provided.
  • the purpose of authentication is to assert the ownership of a service account in the telecommunications network before granting a terminal the access to a service provided from said network.
  • authentication is commonly used, not only in wireless networks (such as cellular networks or WLANs) , but also in other telecommunications networks for which the aforementioned access flexibility exists. Furthermore, it does not necessarily depend on the different kinds of service accounts in what regards to the type of settlement established for paying for the services provided; thus, authentication uses to be common for post- paid and pre-paid service accounts, and also for the so called "voucher accounts”.
  • Voucher accounts are accounts predefined in certain telecommunications networks and, usually, have a limited validity of use from its first activation, which makes them suitable for occasional users of certain telecommunications services. Accordingly, a user may acquire the right to use a voucher account at a sales point and use it for accessing to telecommunications services provided from a telecommunications network for a limited period of time, or other accountable event, such as volume of data or the number of served services .
  • the user is usually provided with the user credentials needed to access the telecommunications network, typically a user identifier, or a user identifier and password (e.g. a card comprising the corresponding user credentials) .
  • the service account data for voucher service accounts are commonly provisioned in the telecommunications network as any other account; i.e. they can comprise essentially the same kind of data as referred above for other kind of service accounts.
  • authentication of a user terminal in both networks might be required; namely, it may be common that, first, the user terminal is authenticated from the first network, so as to allow it to obtain a connection (e.g. a data connection) through said first network which may allow it to communicate with a further telecommunications network, and then, the user terminal is authenticated from the second telecommunications network so as to allow it to access to a service provided from said second network.
  • a connection e.g. a data connection
  • patent application US 2002/0191597 Al discloses an interworking scenario wherein the first network to which the user terminal ("1" in Fig.l of US 2002/0191597) is connected is a GPRS network ("2" in Fig.l of US 2002/0191597) , and wherein the second network providing the final service to the terminal is a IMS network ("7" in Fig.l of US 2002/0191597).
  • a GPRS network 2
  • the user terminal first attaches and is authenticated from the GPRS network, which gives it a data connection through it allowing to further communicate with the IMS network, and then, it is authenticated from the IMS network so as to assert the ownership of the corresponding service account, which gives said terminal the right to access IMS services provided from the IMS network.
  • the present invention allows a user terminal connectable to a first telecommunications network to access a telecommunications service provided by a second telecommunications network via said first network by providing a service account in said second network without a user of the terminal needing to take an active role to subscribe said service account .
  • the method and apparatuses of the invention are characterized in that from the first telecommunications network an account association message is sent to the second telecommunications network, the message requesting the assignation of a service account in said second network and comprising an identifier which is usable as user credentials before said second network, and in that said identifier is stored in the second telecommunications network as user credentials in relationship with a service account which is assigned in said second network upon request from the first network; thereby, allowing from that moment to provide from the second network access to a telecommunications service through the first network to a user terminal connected to the first network for which the ownership of the corresponding user credentials in relationship with the assigned service account can be asserted.
  • service accounts in the second network are dynamically provided upon requests from cooperating first networks
  • occasional users of the services provided by the second network can be alleviated of having to intervene personally so as to subscribe in advance permanent pre-paid or post-paid service accounts in said second network.
  • the operator of the second telecommunications network can be alleviated of having to keep a direct business relationship with all of its eventual users for subscribing and/or maintaining directly the corresponding subscriptions .
  • a service account in the second network can be created at reception of an account association message from a first network, and the identifier comprised in said message becomes user credentials in relationship with said service account being then usable to authenticate a user terminal connected to said first network, so as to allow it to obtain access to a service provided by said second network.
  • the second telecommunications network can store a plurality of identifiers usable as user credentials before said network, wherein a specific set of them, or all of them, can be made accessible for being selected from one or more cooperating first telecommunications networks, through which access to telecommunications services provided from the second network can be requested from user terminals connected to them.
  • these identifiers can be stored in advance in relationship with idle service accounts in the second network, which can be specially devoted for dynamic assignation and activation upon requests from a cooperating first networks.
  • an idle service account in the second network can be set to active at reception of an account association message from a first network comprising the associated identifier, which then becomes user credentials usable to authenticate a user terminal connected to said first network so as to allow it to obtain access to a service provided by said second network.
  • the second network can forward a set of the available identifiers to said first network, or all of them, so as to make possible these identifiers to be stored in the first network and be selected from there.
  • the available identifiers can be keep stored in the second network, wherein a cooperating first network may send a request to obtain one or more of said identifiers which can be available for it.
  • the second telecommunications network can then manage what cooperating first telecommunications network can request dynamic account assignations and, if desired, for what identifiers.
  • the first telecommunications network can store a mark for account association in relationship with some of its service accounts; wherein account association requests can selectively be sent for service accounts which are so marked.
  • an identifier that has been selected for being sent in an account association request from the first telecommunications network to the second telecommunications network is stored in relationship with a service account in the first network; which can also be used as a mark for account association in relationship with said service account, so as to determine the sending of an account association request for said service account .
  • a new marketable concept of combined voucher accounts can be easily deployed, which can allow a user .to acquire a single voucher for connecting to a first telecommunications network and to gain access through it to telecommunications services provided from a second telecommunications network.
  • the acquired voucher would give the user access to first user credentials in relationship with a service account in the first network, which would allow to authenticate a user terminal of the user so as to allow it to access to the first network.
  • the service account in the first network could have been previously marked for account association, so as to provide a further service account in the second telecommunications network and the necessary second user credentials in relationship with said further service account, which would allow to authenticate the user terminal and allow it to access to a telecommunications service provided by the second network.
  • an account association message can also comprise further data that can be stored by the second network as user credentials in relationship with the service account assigned in said second network, so as to grant from the second network the access to a service requested from a user terminal connected to the first network upon authentication of said terminal according to any of the stored credentials.
  • the account association message can comprise user credentials related to said service account. If the account association message is sent from the first to the second network for a user terminal connected to the first network, it can, additionally or alternatively, comprise a trust token identifying univocally said user terminal.
  • the trust token can comprise a network address assigned to the user terminal for communicating with the second network through the first network.
  • the trust token can comprise a key shared between the first terminal and the first network, which may have been established as a result of authenticating from the first network user credentials presented by the user terminals related to a service account in said first network according to a challenge request and challenge response authentication mechanism.
  • the service account assigned in the second network upon request from the first network can be revoked, either: from the first network, or from the second network; thereby allowing to deny further access to the services provided by the second network via the first network when, among other criteria, the service usage, the time elapsed from the association or the volume of data exchanged by the concerned user terminal, exceed a certain limit.
  • an account dissociation message can be sent from the first network to the second network requesting to dissociate a previously associated service account from the corresponding related user credentials. If the initiative is taken from the second network, an account dissociation notification message can be sent from the second network to the first network notifying the dissociation of a service account in the second network that was associated to the corresponding related user credentials upon request from said first network.
  • the account dissociation message and the account dissociation notification message can comprise an information element previously sent in an account association message, which, in the first case, may be used in the second network to identify the concerned service account, and, in the second case, may be used in the first network to identify, if proceeds, the concerned service account in said first network as well as the concerned user terminal .
  • Figure 1 shows a schematic view of a telecommunications system comprising a plurality of telecommunications networks.
  • Figure 2 shows a schematic representation of some functional modules of apparatuses for controlling the access of a user terminal to a service provided from a telecommunications network, as well as some of the data they handle for controlling said access.
  • Figure 3 shows a flowchart illustrating steps of a method for providing access to a telecommunications service according to the invention in interworking scenarios comprising a plurality of telecommunications networks.
  • Figure 4 shows a simplified signaling flow illustrating some embodiments of the method according to the invention.
  • Fig.l represents a simplified view of a telecommunications system comprising three telecommunications networks: IA, IB and 2, which can belong to one or more network operators.
  • IA, IB, 2 Within the domain of each network (IA, IB, 2) a set of state-of-the-art functional server entities 'are depicted, the functionality of which shall be briefly described below.
  • networks IA and IB comprise access means (AP 2A, 2B) for providing access connection for user terminals (UE 11, 12) to said networks.
  • access means schematically represented by access server 2A would comprise radio base stations and base station controllers as well as other access servers entitled to primarily serve the access to the user terminal (e.g. route signaling and media to/from the user terminal) , such as Serving GPRS Support Node(s) SGSNs.
  • access means schematically represented by access server 2B would comprise "hot-spots" of the WLAN network.
  • the server entities illustrated in Fig.l within network 2 represent some of the most common functional elements within the network infrastructure of a (generic) service provider operator which offers services that, for example, might be accessed from a plurality of terminal types connected to different kind of access networks (IA, IB), such as: messaging services, information services according to the current user location, etc.
  • network 2 might represent schematically the IMS network infrastructure of a service provider operator providing IMS services accessible to multimedia-enabled terminals.
  • terminal 11 may be a GPRS enabled mobile phone which, through a connection provided trough a GPRS network IA, access to service network 2 which provides his user with a network-based calendar service, a electronic mail service, a multimedia service, etc; while terminal 12 may be a personal computer equipped with a WLAN card which gives it access trough a WLAN network IB to the same (or similar) services provided from telecommunications network 2.
  • IA, IB, 2 the specific nature of the telecommunications networks used herein as example (IA, IB, 2) , or the specific type of telecommunications services that can be provided from a telecommunications network (e.g. 2) to a user terminal (e.g. 11) connected to another telecommunications network (e.g. IA), are details which do not constrict the scope of the invention.
  • Reference 3 in Fig.l represents schematically an interconnection network that allows the establishment of communications between server entities belonging to telecommunications networks IA, IB and 2, which also allow to establish communications between terminals, or between terminals and servers, connected to different telecommunications networks, so as to convey the necessary signaling and media for the provision of the required telecommunications services.
  • the interconnection network 3 may comprise, for example, intranets, the Internet, dedicated signaling lines, and combinations thereof.
  • Internal communications means within each network are schematically represented in Fig.l by communication lines 6A, 6B and 26.
  • Server entities IGW 5A, 5B, 22 represent interworking server gateways that are commonly used in interworking scenarios involving more than one telecommunications network, which can be used for carrying out a variety of functions, such as protocol translation, proxy functions, routing and/or control functions for signaling or media, etc, that, generally, can be needed when establishing communications between a server (or terminal) belonging (or connected) to the network of an operator and another server (or terminal) belonging (or connected) to the network of another operator.
  • the interworking gateway 5A can represent a Gateway GPRS Support Node GGSN and the interworking gateway 5B can represent a connection server assigned to provide data connectivity to a user terminal 12 connected to the WLAN network IB for communicating beyond the WLAN network domain.
  • the interworking gateway 22 may represent a IMS specific server entity known as "Call State Control Function CSCF" (e.g. in any or all its functional roles; i.e.
  • the interworking gateway 22 may represent router and proxy servers arranged to route and mediate in communications with server entities or terminals in other telecommunications networks. It shall be noticed that the schematic illustration given in Fig.l for the represented interworking gateways IGW (5A, 5B, 22) does not preclude interworking scenarios in which some of the other server entities represented in Fig.l for a given telecommunications network (e.g. 3A or 4A in network IA) are arranged to communicate directly (i.e.
  • two server entities belonging to different telecommunications network may communicate directly if they comprise direct communication links with an interconnection network 3 , use a common communication protocol and, preferably, use an authentication mechanism which allow establish a trusted communication between them.
  • Application servers AS 24 and 25 represent the server entities assigned to accomplish with the execution of high-layer aspects of some telecommunications service (s) that can be provided from the telecommunications network 2.
  • telecommunications service s
  • network IA provides basic (e.g. bearer) data communication services to terminal 11, while network 2 provides some extra telecommunication services.
  • network IA provides basic (e.g. bearer) data communication services to terminal 11
  • network 2 provides some extra telecommunication services.
  • AS 24 and/or 25 can be arranged with the communication means (e.g. protocol stacks, communication links, etc) and service logic (e.g. provided by computer programs comprising the appropriate computer readable instructions to be executed by a processor in the AS) so as to perform intelligent signaling handling for multimedia session (e.g. to divert, accept or reject incoming multimedia sessions for a IMS subscriber based on the time of the day, date of the week, or the identifier of the originator) .
  • communication means e.g. protocol stacks, communication links, etc
  • service logic e.g. provided by computer programs comprising the appropriate computer readable instructions to be executed by a processor in the AS
  • AS 24 and/or 25 can be provided with the appropriate communication means and service logic so as to provide a terminal with a location-based information service; in which case, e.g., AS 24 can obtain from another server in network IA or IB geographical location information of user terminal 11 or 12 (if available) , or even receive it from the terminal, and provide the user terminal with, e.g., information about the nearest hospital, local transport information, local weather forecast, etc.
  • ASs 24 or 25 might cooperate with further servers in other telecommunications networks, which are not necessarily the one wherein the served user terminal is connected to. That could be the case wherein the service provided is, for example, an electronic commerce transaction service (e.g. AS 24 might act as a payment broker server) or when the service provided is, for example, a flight reservation comprising, as an extra feature, the updating of a network-based calendar of the user (e.g. AS 25 might be the flight broker and would have to cooperate with another AS serving a calendar service for the served user, or vice versa) .
  • AS 24 might act as a payment broker server
  • AS 25 might be the flight broker and would have to cooperate with another AS serving a calendar service for the served user, or vice versa
  • the correspondence between server entities cited above may be logically considered in a different way.
  • the basic treatment of a multimedia session within the IMS might not need to imply the intervention of "Application Servers, AS" for intelligent signaling handling as recited above (i.e. Application Servers ASs as referred in the aforementioned specification 23.228, chapter 4.2.4).
  • AS Application Servers
  • the illustrated AS 24 could be a S-CSCF (e.g. the one assigned to serve to the originating user) while the IGW 22 could be a P-CSCF.
  • Fig.l shows networks IA and IB as also comprising application servers (4A, 4B) from which services can be provided to user terminals (11, 12) connected to the same or different telecommunications network.
  • Said services may comprise some of the already related (e.g.: integrated messaging, multimedia calls, personalized information services, presence services, location based services, etc) , wherein the access to some of them could also be allowed, upon previous subscription, for user terminals connected to the telecommunications networks of another operators.
  • network 2 is shown in Fig.l as lacking of access infrastructure where user terminals may directly connect to it (e.g. access servers similar to AP 2A or 2B) , it may also comprise them within its domain.
  • the interworking scenarios detailed herein as examples in which the first (access) network is assumed to be IA or IB, and the second (service) network is assumed to be network 2, may also involve scenarios in which the first (access) network or the second (service) network are any of the telecommunications networks shown in Fig.l.
  • Authentication servers (AA) : 3A, 3B and 23 perform authentication functions on, respectively, each of the illustrated telecommunications networks IA, IB and 2.
  • the specific characteristics of the authentication mechanism (s) that can be utilized in a particular telecommunications network for authenticating a user terminal may vary. Examples of commonly used authentication mechanisms are SIM authentication (as described in chapters 3 or D.3 of 3GPP TS 43.020 V6.1.0, December 2004), Authentication and Key Agreement AKA (as described in chapter 6.3 of 3GPP TS 33.102 V6.3.0, December 2004), and Basic and Digest Access Authentication (as described in IETF RFC2617, June 1999) .
  • any of said AA servers may also vary according to the authentication mechanism (s) they have to use.
  • the basic functional characteristics of authentication servers AA are substantially similar, in so far as they provide the means to assert the ownership of the corresponding service account; for example, by checking directly with the user terminal, or indirectly via a cooperating network, the ownership of the corresponding associated user credentials before granting a terminal the access to a service provided from said network.
  • Authentication mechanisms commonly rely in user credentials comprising at least a secret key shared between the telecommunications network and the user, his terminal or a usually tamper-resistant device connectable to the user terminal (or embedded on it) that is arranged to contain a secret key (such as a SIM card or another kind of similar smart card) .
  • the authentication procedure usually involves an interaction between the user terminal and the authenticating network in which the user terminal is asked to provide the user credentials (which may require an interaction with the user) that are then verified by the network.
  • authentication server may be directly or indirectly involved in the authentication process; i.e., the authentication server may check directly the credentials submitted by the user terminal, or may send the necessary authentication material to a server entity primarily contacted from said terminal.
  • authentication server 3A e.g. a Home Location Register with Authentication Centre capability HLR/AuC of a cellular network IA
  • authentication material e.g. GSM triplets
  • access server 2A e.g. SGSN or MSC/VLR
  • authentication server 23 e.g.
  • a RADIUS authentication server may run directly the authentication of a user terminal when accessing to network 2, e.g., by verifying that the user terminal owns the corresponding user credentials, by asking the user of the terminal to enter a user identifier and/or a password, etc.
  • authentication server 3B on network IB may check user credentials received from the user terminal 12, such as user identifier and/or a password, while authentication server 23 (e.g. a Home Subscriber Server HSS of a IMS network 2) may send authentication material (e.g. Authentication Vectors) to the S-CSCF (22, 24) so as to authenticate a user terminal from there.
  • authentication material e.g. Authentication Vectors
  • a further interworking scenario that could be embodied by the schematic illustration represented in Fig.l is that any of the access networks IA or IB may in turn be comprised of two sub-networks. That can be the case wherein network IA would comprise, for example: a WLAN radio access infrastructure comprising WLAN hot-spots and WLAN access server (s) , to which the hot-spots are connected, and an interworking cellular network providing IP connectivity trough its GPRS access infrastructure.
  • network IA would comprise, for example: a WLAN radio access infrastructure comprising WLAN hot-spots and WLAN access server (s) , to which the hot-spots are connected, and an interworking cellular network providing IP connectivity trough its GPRS access infrastructure.
  • IGW 5A represented in Fig.l would comprise the Packet Data Gateway PDG disclosed in said specification, and the AA 3A could be the named 3GPP AAA Server. Accordingly, the user terminal 11 would be given access if the existence of a service account in the GPRS (sub) network is
  • an authentication server executes directly the authentication of a user terminal (11, 12) that accesses, either: directly or through another telecommunications network, to the telecommunications network where it resides (IA, IB, 2) .
  • the functionality disclosed for an authentication server may be shared with another servers performing another functions (such as access control or signaling handling) .
  • a particular telecommunications network may (e.g. due to scalability and/or reliability reasons) have a plurality of authentication servers.
  • a particular authentication server (3A, 3B, 23) may also be arranged to perform further functions such as service authorization and accounting functions.
  • authorization and authentication functions are closely related, since, when the access to a service is subject to a previous subscription, the access to said service uses to be subject to authorization, which leads to a previous authentication.
  • authentication and authorization functions for a given terminal connected to a telecommunications network uses to be performed by the same kind of authentication server entity, which functional role is, in summary, to control in a given telecommunications network the access of a user terminal, which is directly or indirectly connected to said network, to a telecommunications service provided by said network or provided from another telecommunications network.
  • accounting of the services requested and consumed by a user use to be performed by the same server that authorizes said services. Therefore, authentication, authorization and accounting functions are commonly performed by the same kind of server (usually known as AAA server) .
  • authentication servers 3A or 3B are assumed to be the servers entitled for controlling from a first network (IA, IB) the access of a user terminal (11, 12) to a telecommunications service provided from a second network (such as network 2) through said first network (IA, IB)
  • authentication server 23 is assumed to be a server entitled for controlling from telecommunications network 2 the access of a user terminal to a service provided by said network .
  • Fig.l The internal simplified structure of an authentication server AA (3A, 3B, 23) shown in Fig.l shall now be described with reference to Fig.2, which considers a possible implementation as a computer-based apparatus, which, as in most of the modern telecommunications networks, is a preferred implementation basis for telecommunication servers .
  • a telecommunications server which serves or mediates in the services provided by or through a telecommunications network may be considered as comprising of one or more functional modules, each of them arranged to perform a specific sub-function of the total functionality implemented by said server and, eventually, arranged to cooperate with some of the others. Furthermore, the functionality of a given telecommunications server
  • a functional entity may be distributed across various physical machines, each performing a part of the total functionality said server is assigned to perform.
  • An example of this is a HSS comprising a first machine implementing HLR functionality and a second machine implementing AuC functionality.
  • the same physical machine may implement the functionality of two or more different servers (e.g. a computer-based machine may implement the functionality of two functional entities such as a SGSN and a GGSN, or the functionality of two ASs providing two different services) .
  • a server implemented as a computer-based apparatus comprises: software and hardware, which can be distributed along various cooperating physical machines; wherein a specific functional module of the server implemented by a computer-based apparatus may comprise : software, hardware, or a combination of both, and wherein said functional modules are designed to perform a specific (sub) function and, if proceeds, to cooperate with software and/or hardware parts which implements other functional module (s) .
  • the software comprises one or more computer programs (computer readable program code) that, when executed by a computer-based apparatus makes it to behave according to a predefined manner, as determined by the specific program instructions in said programs, which is in accordance to its specific functionality.
  • the simplified internal structure shown in Fig.2 for authentication server 3A or 3B comprises: a processing module 301, a communications module 302, a data storage module 303 and one or more internal communication buses 304 which allow data communication and cooperation between them.
  • a processing module 231 a processing module 231, a communications module 232, a data storage module 233 and internal communication buses 234.
  • each of the processing modules can comprise, respectively, one or more processors (illustrated, respectively on each server, as 3010 and 2310) , which can be arranged to work in load-sharing or active-backup mode.
  • Processor 3010 in AA 3A executes service logic for checking if user credentials received from a user terminal 11 connected to network IA relate to a service account in said network, so as to allow said terminal to obtain a service from said network IA.
  • the service may comprise the provision to terminal 11 of a connection through the network IA, which may be used by terminal 11 to access to a further network (e.g. IB or 2) .
  • a similar service logic is executed (mutatis mutandis) by processor 3010 in AA 3B for user terminal 12 connected to network IB.
  • Processor 2310 in AA 23 executes service logic for checking (directly with the user terminal, or indirectly via the cooperating access network IA or IB) if user credentials received for a user terminal (11, 12) relate to a service account in the network 2 before allowing the user terminal to obtain access to a telecommunications service provided by said network.
  • the service logic executed by processors (3010, 2310) in authentication servers 3A, 3B and 23 is further enhanced with the novel functionality of the invention that shall be later detailed.
  • a communications module 302 that is illustrated as comprising two communication devices 3021 and 3022.
  • the communications module 232 also comprises two communication devices 2321 and 2322.
  • the communications module allows an authentication server to exchange signaling with other server entities, including another authentication server (s), so as to accomplish with its function.
  • some of the communication devices (2321, 2322) of an authentication server (23) may be devoted to a specific kind of communication (e.g. only with some other server entity with which a standardized or proprietary signaling interface is used, only for a given type of communication protocol, etc) . Also, some of said communication devices may be suited to allow any kind of communication that may be handled between the authentication server (23) and another server entity (24, 25, 22), including another authentication server (3A, 3B) .
  • RADIUS protocol (IETF RFC2865, June 2000) or DIAMETER protocol (IETF RFC3588, September 2003) are example of communication protocols that are commonly used by authentication servers (3A, 3B, 23) to communicate with other server entities in a telecommunications network (such as access servers or even another authentication servers) and that can be easily extended, which allow them to convey new messages and/or new or modified contents for new kind of applications .
  • the number of communication devices (e.g. 3021, 3022) in the communications module (302) of an authentication server (3A) may vary according to their respective capacity for handling signaling to/from another server entities compared with the overall signaling estimated for the authentication server (3A) .
  • the communications module (e.g.
  • an authentication server (3A) may comprise some functional or physical elements (hardware, software or combination) that may be common to one or more communication devices (3021, 3022) , such as a part of a given communications protocol stack, being the other (protocol specific) parts residing on the corresponding communication device.
  • Data storage modules 303 and 233 store data needed for the operation of, respectively, authentication server 3B (or 3A) and 23.
  • Each data storage module may comprise one or more data storage devices (illustrated as 3031 and 3032 for servers 3A or 3B, and 2331 and 2332 for server 23) , which may comprise memory chips, magnetic or optical discs, etc, and combinations thereof; wherein the data storage module (233) of an authentication server (23) may incorporate one or more storage devices (2331, 2332) of the same or different kind according to different implementation criteria, such as data access speed required or the reliability desired for certain stored data.
  • the data storage module of an authentication server can reside within the same physical machine, or can be distributed.
  • computer readable program code that may be needed to control the operation of the authentication server 23 as well as temporary data storage of dynamic information (e.g. information related to currently registered user terminals) may reside within the same physical machine hosting the processor (s) of the processing module, while some other data, such as part or all of subscriber data, may be stored in another machine, such as an external database (not shown in Fig.l), and obtained/updated remotely.
  • FIG.2 illustrates schematically some of the data that can be handled by authentication servers 3A or 3B, and authentication server 23, which shall now be described.
  • Fig.2 all the illustrated data (303-1, 303-2, 233-1, 233-2, 233-3) appear as belonging to the corresponding storage module (303, 233) ; however, as commented above, for a particular authentication server this not implies that all these data belong to its own storage means.
  • authentication server 3B The operation of, e.g., authentication server 3B is controlled by computer-readable program code 303-1 comprising instructions (CI-Il..., CI-IN) that, when executed by processor 3010, make authentication server 3B to perform as described heretofore, and also performing new functions according to embodiments of the invention.
  • computer-readable program code 233-1 that comprises instructions (CI-21..., CI-2N) adapted to be executed by processor 2310 so as to perform the aforementioned functions and also new functions according to embodiments of the invention, which shall be later described.
  • reference 303-2 represents the set of data that constitute the service accounts of, e.g., subscribers of network IB, and reference 233-2 the service accounts of subscribers of network 2.
  • data related to a service account may be dynamically provided within the telecommunications network upon subscription of the service account.
  • some of said data may be already preset with some values (e.g. from default subscription data templates) , wherein a particular service account could be marked as "idle” while not yet subscribed by any user, and then marked as "active" upon account subscription from a user.
  • service accounts 233-2 would represent active service accounts
  • service accounts 233-3 would represent idle service accounts which, according to an embodiment of the invention, may be assigned in telecommunications network 2 upon requests from another telecommunications network (e.g. 3B, 3A), e.g. by- setting the necessary further data on them, so as to set them as active (subscribed) service accounts; namely, as if they were service accounts subscribed directly by the users .
  • another telecommunications network e.g. 3B, 3A
  • Fig.2 also illustrates the content of a generic service account SA-IN in, e.g., network IB, and a generic service account SA-2N (or SA-2M) in network 2. It shall be noticed that the illustration does not intend to refer to any particular storage data structure for keeping in relationship the relevant data of a particular service account, an implementation detail which is not relevant for the invention.
  • the data in the service account of a subscriber in a given telecommunications network may vary according to a plurality of factors such as: the nature of the services provided by said network (e.g. if they may be served to any subscriber without restriction and/or personalization, or not) , the nature of the access that can be utilized from user terminals (e.g. if said terminals are always connected to the same access point, or if the access point may vary) , and also depending on the operator of the network " (e.g. two cellular operators owning different cellular networks may store some different data) .
  • one data that can be stored in relationship with a service account may be the account status AST, which may store a value indicating whether the service account is in fact active or idle, and which can advantageously be used to determine in a given moment whether the data in the service account are usable to provide or grant access to a service which is subject to the subscription of a service account.
  • a user terminal (11, 12) is not supposed to be always connected (directly or indirectly) to a telecommunications network (IA, IB, 2) , but it is expected that the terminal may dynamically attach/detach to it or, more generally, when said terminal may dynamically register/deregister in one, or more, telecommunications networks, then, information about the registration status RST of a user terminal for a particular subscription may also be stored in relationship with other data in the corresponding service account.
  • the registration status RST can be used to determine, for example, whether an incoming service (e.g.
  • an incoming call or multimedia session, data pushed from an application server, etc) may be delivered to the corresponding user terminal, or shall be treated in other way, and can also be usable to start the execution of some actions from the authentication server (3A, 3B, 23) depending on its value (e.g. depending on whether the terminal is registered, registering or unregistered) .
  • user credentials CXl are stored in relationship with the corresponding service account so as to authenticate it before granting access to a service provided from (by or through) network IB.
  • user credentials CX2 to assert the existence of a service account are stored in relationship with his corresponding service account in network 2.
  • authentication can take place, not only when the user terminal request access to the telecommunications network (e.g. at registration), but also after a certain period of time and/or upon request of some service.
  • a user terminal may be requested to authenticate when it request a service from a telecommunications network (IA, IB, 2) , since an access request message (e.g. a SIP message "register", or an equivalent access request message which request registration of a user from a terminal in a network) gives, when accepted by the receiving network, granted access to said network, which may also be considered as a service provided from said network.
  • an access request message e.g. a SIP message "register”, or an equivalent access request message which request registration of a user from a terminal in a network
  • a service account may comprise some dynamic data which can be relevant when a user terminal is connected to network IA or IB.
  • the service account related to a registered (attached) terminal 12 in network IB can comprise a token CTK comprising information which univocally identifies said terminal in its current active connection.
  • the token CTK can comprise, for example, a network address (e.g. an IP-address) assigned to terminal 12 and usable to communicate with servers (e.g. 4B) in network IA, as well as with servers in other networks (e.g. 4A, 24, 25, etc) .
  • the token CTK can comprise a key that may have been derived as a result of authenticating from a telecommunications network a user terminal according to a challenge-request/challenge- response authentication mechanism.
  • additional keys are derived (both: in the network and in the user terminal) from user credentials in challenge request/challenge response authentication mechanisms, such as the aforementioned SIM authentication or AKA (e.g. a "Ciphering Key” Kc is derived in SIM authentication, and "Ciphering Key” and “Integrity Key” are derived in AKA authentication) .
  • the token information CTK can be used for various purposes, such as for delivering it to a further server so as to encrypt/decrypt from there information sent/received to/from the user terminal (e.g. in case it comprises a derived key) , or for delivering it to a server needing to route some data to a user terminal (e.g. in case it comprises a network address) .
  • IA or IB can, according to the invention, comprise further data (MRK, 1X2) that shall be referred in the following description given with reference to the flowchart of Fig.3 and to the signaling flow of Fig.4.
  • Fig.3 illustrates the steps of a method for providing a user terminal (11, 12) connectable to a first telecommunications network (IA, IB) with access to a telecommunications service provided from a second telecommunications network (2) through said first network (IA, IB) .
  • a service account is provided in the first telecommunications network (e.g. IB) comprising the necessary user credentials (CXl) .
  • This allow to authenticate a user terminal (11, 12) so as to allow it to access to a telecommunications service provided by the first network (11, 12) , such as the obtainment of a connection through the first network, which can allow the user terminal to communicate with servers in further telecommunications networks.
  • step 52 represents that a service account is provided in the second telecommunications network 2, and that the corresponding user credentials (CX2) are stored in relationship with it so as to authenticate a user terminal (11, 12) before granting it access to a service provided from the second telecommunications network.
  • steps 51 and 52 represent the provision for a user of, respectively, a first service account SA-IN in a first network IA or IB, and a second service account SA-2N in a second network 2, wherein the provided service accounts comprise, at least, user credentials CXl, CX2 , that allow a user terminal 11 or 12 to access to the services provided respectively by said fist and second networks.
  • a user terminal 11 or 12 connectable to a first network IA or IB may access to a service provided from a second network 2 through a connection provided by the first network when said terminal connects to it. Subsequent steps 53 to 56 take place when a user terminal connects to a first network and access through it to a service provided by a second network.
  • step 53 when user terminal 12 request access to a service provided by network IB it is authenticated from there in step 53. If the terminal 12 proves the ownership of the corresponding credentials (CXl) , authentication is successful and a connection through network IB is provided to the user terminal 12 in step 54
  • connection through network IB can comprise, for example, the assignment of a IP-address to the terminal 12, and/or the provision of an internal communication channel between the terminal 12 and the IGW 5B and the assignment of e.g. a globally routable IP- address in relationship with said channel in the IGW 5B, which would allow (e.g. using address translation) to route information to/from the terminal, via the internal channel, to/from another external server in another telecommunications network (e.g. network 2) .
  • the user terminal 12 may then request access to a service provided by network 2. For example, the user terminal sends a service request message to a server in network 2 which request explicitly a given service, or which request a generic access to a set of services that can be provided from network 2 (e.g. an access request message such as a SIP "register” message) .
  • authentication for user terminal 12 is carried out from network 2, which, for example, can comprise a direct interaction between an authentication server in network 2 (23) and user terminal 12, and/or an interaction between an authentication server in network 2 (23) and an authentication server in network IB (3B) , so as to assert the ownership of the corresponding credentials (CX2) before granting user terminal 12 the access to the requested service.
  • the access to the requested service is provided in step 56.
  • the step (52) of providing a usable service account SA-2N in the second network 2, by storing in said network 2 at least the corresponding user credentials CX2 in relationship with said service account may by accomplished by a set of steps (522, 524, 526) that, according to the invention, can alleviate a user of having to take an active role (e.g. being personally involved in some administrative transaction) for subscribing a further service account in a further network (e.g. network 2), when he already has got a subscription in another network (e.g. network IA or IB) .
  • an active role e.g. being personally involved in some administrative transaction
  • a further service account in a further network e.g. network 2
  • another network e.g. network IA or IB
  • an identifier 1X2 is selected from the first network (IB) .
  • the identifier is such that it is usable as user credentials before the second network (2) .
  • the selected identifier 1X2 is a data element having a format that can be accepted by e.g. authentication server 23 as user credentials for granting access to a terminal (12) to a service provided by network 2; thus, it may comprise: a single component (e.g. an arbitrary alphanumeric string, or a structured string, such as a SIP- URI as defined by IETF RFC3261, or a NAI as defined by IETF RFC2486) , or a complex component (e.g. containing a first component to be used as user-identifier, and a second component to be used as password) .
  • a single component e.g. an arbitrary alphanumeric string, or a structured string, such as a SIP- URI as defined by IETF RFC3261, or a NAI as
  • network IB may store a set plurality of said identifiers (e.g. in a database belonging or accessible to AA server 3B) , wherein the selection of step 522 would comprise to select an available identifier 1X2 stored by the first network IB.
  • the plurality of identifiers that can be selected from a first network (IA, IB) can be primarily stored by the second network 2, wherein a specific set of them, or all of them, can be made accessible for being selected from one or more cooperating, first telecommunications networks (IA, IB) .
  • a first option for making them accessible for selection to a particular cooperating first network is to send sub-sets of said identifiers from network 2 to, respectively network IA and network IB.
  • a second option is that, for selecting available identifier (s) , a server in a first network (e.g. AA server 3B) sends a request for one or more identifier to a server (or accessible database) in network 2 (e.g. AA server 23) .
  • the second telecommunications network 2 can manage what cooperating first network can request an account association according to the invention.
  • idle service accounts 233-3 are pre-defined (e.g.
  • the corresponding identifiers that shall be used as credentials for said idle accounts can be stored in relationship with them,- thereby, allowing to pre-define also certain (default) data in said accounts in network 2, which may vary according to the first network (IA, IB) to which the corresponding identifier (s) is (are) made accessible. Accordingly, the access to certain services in network 2 may be advantageously controlled (e.g. barred, limited, etc) depending on the first network IA, IB to which the requesting user terminal 11, 12 is attached.
  • an account association message is transmitted from the first network (e.g. IB) to the second network 2 comprising the selected identifier.
  • the message requests to assign a service account in the second network 2 in relationship with said identifier 1X2.
  • the received identifier 1X2 is stored as the corresponding user credentials CX2 in relationship with a service account assigned in network 2.
  • the assigned service account can be new service account SA-2N which is provided in that moment.
  • step 526 may comprise the setting in network 2 of an idle service account SA-2M as an active service account SA-2N.
  • the corresponding idle service account SA-2M that is to be activated (SA-2N) can be identified according to the received identifier 1X2, for example, if it had been pre-stored in advance as user credentials CX2 for said idle service account SA-2M.
  • the idle service account SA-2M could have been (pre) assigned in network 2, for example, when an available identifier 1X2 was sent to, or selected by, networks IA or IB, as recited above.
  • the selected identifier (s) 1X2 is (are) preferably marked as not selectable in the corresponding network (IA, IB, 2) ; thereby, avoiding to associate two service accounts SA-2N in the second network with the same user credentials.
  • a terminal (11, 12) which can benefit from the service account provision process described heretofore (steps 522, 524, 526) does not need to be connected to the first network (IA or IB) when said process takes place, and that it is sufficient it is arranged to connect (i.e. connectable) to it.
  • a mark for account association MRK (Fig.2) can be stored in relationship with one or more service accounts SA-IN in a first network (IA, IB) ; thereby, allowing to determine whether an account association message can be sent to the second network 2 in relationship with a service account SAIN in the first network IB, independently on whether a user terminal (11, 12) is currently registered for said service account (e.g.
  • account association messages can be sent from a first network (IA or IB) to the second network 2, for example: as a part of a batch process performed by the first network, upon account provision/activation in the first network, or when a user terminal (11, 12) registers for a particular service account in a first network.
  • a single account association message can be sent comprising a plurality of selected identifiers 1X2, and requesting to assign a service account SA-2N in network 2 for each of them, wherein each identifier 1X2 would become user credentials CX2 in relationship with the corresponding service account SA-2N.
  • An identifier 1X2 that has been selected (step 522) for being sent in an account association message can be stored in relationship with a service account SA-IN in the first network IB as the mark MRK for account association.
  • the mark MRK for account association can comprise a single (e.g. binary) value which determines a yes/no condition for sending an account association message, or can comprise another kind of value, wherein the condition for sending or not the account association message can be the existence of a value different from a pre-defined default value.
  • the selected identifier 1X2 (or the plurality of them, as will be later referred) may be stored in relationship with a service account SA-IN in the first network.
  • this can allow to reuse the same identifier 1X2 in situations wherein the assigned service account in the second network 2 can be revoked (as will be later detailed) and it is desirable to use the same identifier 1X2 in relationship with the same service account SA-IN in a further assignation requested from the first network IB.
  • Transition flow lines marked as X-Y and U-W in Fig.3, illustrate an embodiment in which the process comprising the steps 522, 524 and 526, is performed when a terminal (11, 12) is connected to the first network (IA,
  • steps 522, 524 and 526 can take place after successful authentication 53 of the user terminal (as indicated by transition X-Y) , or, after authentication, when a connection through the first network is provided 54 to the user terminal (as indicated by transition U-V) , which, for example, can be the case if the successful authentication in network IB involves the provision of connection through network IB, or if the user terminal has requested explicitly said service (or a service that requires it) .
  • step 522 can be performed for a service account SA-IN in the first network IB before any terminal has registered for it (i.e. an identifier 1X2 is selected for said service account)
  • steps 524 and 526 can take place when a user terminal 12 registers for it after being successfully authenticated according to the corresponding credentials CXl.
  • steps 522 to 526 can take place independently of any service account in the first network IB, wherein the identifiers 1X2 that were sent in account association messages (step 524) are kept as pre- assigned in network IB, and wherein one of them can be later assigned to a service account SA-IN in said network, for example, after successful authentication of a terminal 12 according to the credentials CXl of said service account .
  • Fig.4 shows a simplified signaling flow representing a user terminal 12 connecting to a first network IB and accessing to a telecommunications service provided by an application server 25 in a second network 2 which is subject to subscription in said second network, in the depicted signaling, authentication servers 3B and 23 in, respectively, networks IB and 2, appear as interacting directly with the user terminal 12 or between them.
  • authentication servers 3B and 23 in, respectively, networks IB and 2
  • networks IB and 2 appear as interacting directly with the user terminal 12 or between them.
  • some of the steps aforementioned are illustrated as performed by servers 3B and 23.
  • there can be more intervening cooperating servers entities which, for the sake of clarity, are not shown in Fig .4.
  • Storage 70 represents a database in network 2 that stores the available identifiers 1X2 that can be used as user credentials CX2 in relationship with service accounts that can be assigned in network 2 upon request of other networks (IA, IB) . Some of these identifiers, or all of them, can be made accessible to network IB, wherein flow 601 can represent: the request for one or more of these identifiers from network IB and the subsequent delivery from network 2, or a direct delivery of one or more of these identifiers without a previous request. Flow 601 may also represent an updating sent from network 2 to network IB about the currently available identifiers (e.g.
  • storage 7OB represents a database in network IB that stores the identifiers 1X2 received (or obtained) from network 2.
  • Storages 70 and 7OB can be stand-alone databases, or can respectively belong to other servers (e.g. they can respectively belong to authentication servers 3B and 23) .
  • Dots in flow 601 illustrate a possible embodiment in which any of the authentication servers (3B, 23) is involved in the obtainment/sending of identifiers 1X2 between network 2 and network IB .
  • the user terminal 12 sends an access request message to network 2.
  • the authentication server 3B runs in step 53 the authentication of the user terminal .
  • the message in 602 can comprise a user identifier assigned to the user of the terminal (or an identifier assigned to the terminal) in relationship with a service account in network IB, which can be the user credentials CXl for said account (e.g. received in clear, or encoded according to a pre-defined key or encoding mechanism) .
  • the authentication step 53 may comprise the verification by server 3B that the received user identifier corresponds with the credentials stored in relationship with a service account in network 2.
  • the received user identifier can be used by the authentication server 3B to find out the related service account and, subsequently, the corresponding user credentials CXl.
  • the authentication step 53 can comprise the sending of a challenge to the user terminal to assert the ownership of the user credentials CXl, the reception of the subsequent challenge response, and its verification (flows not shown in Fig.4) .
  • some service accounts SA-IN may have been marked MRK for account association. This is illustrated in Fig.4 by step 521 (not shown in Fig.3). Accordingly, if the user terminal 12 is successfully authenticated, the value of the mark for account association MRK is checked in the service account used by the terminal 12 on its registration. For example, the user of terminal 12 has acquired a voucher account in a sales point and, as a result of the transaction, he has been provided with e.g. a card or another kind of item bearing the corresponding user credentials CXl to access to network IB, e.g. during a given period of time, wherein the agreement of the acquisition comprises the right of accessing to a further telecommunications network (e.g. network 2, and/or other networks) through network IB. On network IB, the corresponding service account SA-IN had been marked MRK for account association, and the mark can be checked when the user attach its terminal to network IB, as illustrated in step 523.
  • a further telecommunications network e
  • voucher accounts i.e. service accounts generally intended for a short-term use, and thus, being usually intended for very occasional users of the services of a telecommunications network.
  • the service account of a pre-paid or post-paid subscriber in a telecommunications network can benefit from the combination with service accounts in further telecommunications networks by the automatic assignation process of the invention; wherein, the operator of a given network may, for example, reward some of its subscribers with a temporary subscription to a services provided by other networks that can be accessed through its network, or wherein the operator of a given network (e.g. a service provider), willing to promote some new service (s) signs service agreements with other operators which has a widely deployed access networks (e.g. network providers), so as to make some subscribers of said other operators to experience said service (s).
  • a service provider willing to promote some new service (s) signs service agreements with other operators which has a widely deployed access networks (e.g. network providers), so as to make some subscribers of said other operators to experience said service (s).
  • an identifier 1X2 usable as user credentials before network 2 can be selected at that point, if not selected previously for said service account SA-IN.
  • Flow 522-a represents an embodiment referred earlier in which authentication server 3B selects an identifier from storage 70 in network 2
  • flow 522-b represents another embodiment in which the identifier is selected from storage 7OB in network IB.
  • the selected identifier 1X2 is then sent in an account association message 524 to network 2, e.g. to authentication server 23) , which then stores the received identifier as user credentials CX2 in relationship with a service account SA-2N that is assigned in network 2, as illustrated by step 526.
  • more than one identifiers 1X2 can be selected to be used in relationship with a service account SA-IN in the first network IB, each one usable as user credentials CX2 before further second networks, wherein more than one account association messages 524 could be sent; thereby allowing the user of terminal 12 to access from network IB to the services provided from further telecommunications networks (2, IA, etc) which are subject to subscription in said networks .
  • Flow 603 represents an acknowledgement message that can be sent to the user terminal 12 so as to notify the successful result of the access request (602) .
  • the user terminal gets a connection through network IB.
  • the selected identifier 1X2 can be sent within the acknowledgement 603, or can be made accessible to the user terminal 12 by other means (e.g. sent to the terminal in another message upon reception of a specific request) .
  • the sending of the selected identifier 1X2 to the user terminal 12 can be facultative, as it depends on the kind of authentication that can be requested, or accepted, by authentication server 23, which can vary depending e.g. on special mark (not shown in Fig.2) associated to service accounts assigned SA-2N upon request from a cooperating first network (IA, IB) .
  • network IB can obviate the storage of the selected identifier in relationship with the corresponding service account SA-IN in said network.
  • the account association message 524 can comprise further data that can also be stored (step 526) in network 2 as user credentials CX2 in relationship with the assigned service account SA-2N, so as to later grant from authentication server 23 the access to a service of network 2 requested by user terminal 12 by authenticating the request made from the terminal according to any of the stored credentials.
  • the account association message can comprise credentials CXl of the service account SA-IN in network IB that were used to authenticate user terminal 12.
  • the account association message can comprise the aforementioned connection token CTK, which can also be used as a trust token so as to allow univocal identification of the user terminal 12 connected to network IB.
  • the connection token CTK may thus be used as some kind of authentication artifact that can be asserted from network IB.
  • the user terminal 12 For accessing to a service provided from network 2, the user terminal 12 sends in flow 604 a service request message.
  • the network 2 may require that the user terminal first register on it. Therefore, as commented earlier, the message represented by flow 604 can be a service request message requesting registration.
  • authentication server 23 determines that there is no ongoing session authenticated for user terminal 12 (e.g. no active registration RST, a pre-determined time has lapsed from the last authorized service request, etc) , authentication takes place in step 55.
  • authentication 55 can be carried out in a simple manner; for example, the authentication server 23 may examine the content of the received message and check if any of its information elements comprise credentials CX2 stored in relationship with a service account SA-2N. Accordingly, the authentication server 23 may examine e.g. the IP-address corresponding to the origin of the message. Also, the user terminal can include in the request 604 a data element that were stored as credentials CX2 in step 526, such as the credentials CXl in the network IB, or the credentials CX2 that were received from network IB upon successful authentication from there (step 53) , or a key derived as a result of said authentication, which can be used by authentication server 23 to perform the authentication of the terminal 12.
  • a data element that were stored as credentials CX2 in step 526, such as the credentials CXl in the network IB, or the credentials CX2 that were received from network IB upon successful authentication from there (step 53) , or a key derived as a result of said authentication, which can be used by authentication
  • Step 55 may also comprise an interaction (not shown in Fig.4) between the authentication server 23 and the terminal 12 and/or between the authentication server 23 and the authentication server 3B.
  • step 55 can comprise the sending of a challenge to the user terminal 12 (e.g. requesting a user-identifier and/or a password, or requesting to cipher a given random string with a certain key known by the authentication server and, supposedly, known also by the user terminal) to assert the ownership of the user credentials CX2 , the reception of the subsequent challenge response, and its verification.
  • step 55 can comprise a check requested from authentication server 23 to authentication server 3B about the current validity of certain data element presented by the user terminal 12 as user credentials CX2 before network 2 in the message 604.
  • the user terminal 12 gets granted access 56 to the service provided from application server 25.
  • accounting functions can be performed in either or both telecommunications networks IB and 2.
  • server 3B in network IB can keep track about: the connection time spent by terminal 12, the volume of data exchanged with other servers or terminals, the services requested from network IB, etc, and server 23 can perform similar accounting functions about the consumed services, time, data volume, etc, in respect of network 2.
  • the accounting information in both networks may be associated
  • the usage of the service account SA-2N assigned in the second network 2 may be revoked due to different reasons, such as when the service usage (either or both: in network IB or network 2) , the time elapsed from the association request (step 524) , the volume of data exchanged by user terminal 12, etc, exceed a certain limit, or, for example, when the credit of the service account SA-IN used by the user terminal 12 in the network IB (e.g. a pre-paid account or a voucher account) gets exhausted. Therefore, the initiative for the revocation is preferably taken by any of the telecommunications networks involved in the account association.
  • FIG.4 shows authentication servers 3B and 23 directly involved in the signaling and its processing, however, other servers in networks IB and 2 can, additionally or alternatively, be involved in the process .
  • an account dissociation message 605-a can be sent from server 3B in network IB to server 23 in network 2 requesting to dissociate a previously associated service account SA-2N in network 2 from the corresponding related user credentials CX2.
  • Flow 605-b shows the case in which the initiative is taken from network 2, wherein network IB is notified that the dissociation has been executed in network 2 with the reception of an account dissociation notification message.
  • flow 605-b can also represent a confirmation from network 2 that the request made in flow 605-a has been executed by network 2.
  • Flows 606 and 607 represent possible embodiments wherein the concerned identifier 1X2 is set again as selectable for further account association in the corresponding storage (s) 70 and/or 7OB.
  • the account dissociation message 605-a can comprise the identifier 1X2 that was sent in an account association message 524. Additionally, or alternatively, it can comprise one or more of the information elements previously sent in an account association message 524, such as the selected identifier 1X2, the trust token CTK, or the credentials CXl in the first network IB.
  • the content of message received by network 2 in flow 605-a can be used to identify in step 528 the concerned service account SA-2N and to unbind in network 2 the relationship established between the selected identifier 1X2, or any other information element received (524) as credentials CX2 for the assigned service account SA-2N, and said service account SA-2N.
  • step 528 may comprise the setting of the concerned service account SA-2N back as an idle service account SA-2M.
  • the content of message received by network IB in flow 605-B may be used in step 529 to identify, if proceeds, the concerned service account SA-IN in network IB; for example: if a terminal is registered for it and is to be notified, if it is desirable to remove the stored mark MRK or identifier 1X2 stored in relationship with the concerned service account SA-IN, etc, and, in general, whenever it is needed to obtain a data stored in relationship with said service account.
  • the mark for account association MRK can be kept in relationship with the concerned service account SA-IN in the first network IB, which can allow a further service account association in the network 2 using the same or a different identifier 1X2 as user credentials CX2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Meter Arrangements (AREA)

Abstract

L'invention concerne un procédé et des appareils permettant de donner à un terminal utilisateur (11, 12) connectable à un premier réseau de télécommunications (1A, 1B) l'accès à des services de télécommunications fournis par un second réseau de télécommunications (2) sur ledit premier réseau. Un identificateur IX2 utilisable en tant que justificatif d'identité avant que le second réseaux soit sélectionné (522). Un message d'association de compte (524) est envoyé par le premier réseau de télécommunication, demandant l'attribution d'un compte de service (SA-2N) et comprenant l'identificateur sélectionné IX2. L'identificateur XI2 est stocké (526) dans le second réseau de télécommunication sous forme de document d'identité d'utilisateur CX2 pour un compte de service SA-2N dans ledit second réseau. Etant donné que les comptes de service dans le second réseau sont fournis par les réseaux coopérants, des utilisateurs occasionnels de services fournis dynamiquement par le second réseau peuvent être dispensés d'intervenir personnellement pour souscrire à l'avance des comptes de service post-payés dans ledit second réseau.
EP05752739A 2005-06-15 2005-06-15 Procede et appareil de fourniture d'un service de telecommunications Withdrawn EP1891821A2 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2005/000916 WO2006135285A2 (fr) 2005-06-15 2005-06-15 Procede et appareil de fourniture d'un service de telecommunications

Publications (1)

Publication Number Publication Date
EP1891821A2 true EP1891821A2 (fr) 2008-02-27

Family

ID=36293284

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05752739A Withdrawn EP1891821A2 (fr) 2005-06-15 2005-06-15 Procede et appareil de fourniture d'un service de telecommunications

Country Status (2)

Country Link
EP (1) EP1891821A2 (fr)
WO (1) WO2006135285A2 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2092763B1 (fr) 2006-10-23 2019-03-27 T-Mobile USA, Inc. Système et procédé pour gérer une fonctionnalité et une configuration de point d'accès
US9332000B2 (en) * 2008-02-21 2016-05-03 Alcatel Lucent One-pass authentication mechanism and system for heterogeneous networks
US8885635B2 (en) 2008-07-17 2014-11-11 T-Mobile Usa, Inc. System and method for selectively provisioning telecommunications services between an access point and a telecommunications network using a subscriber identifier
US8953620B2 (en) 2008-07-17 2015-02-10 T-Mobile Usa, Inc. System and method for selectively provisioning telecommunications services between an access point and a telecommunications network using a subscriber identifier
US8619545B2 (en) 2008-07-17 2013-12-31 T-Mobile Usa, Inc. System and method for selectively provisioning telecommunications services between an access point and a telecommunications network based on landline telephone detection
GB2467597B (en) 2009-02-10 2012-12-26 Oracle Int Corp Integrated communication system and method
US8320344B2 (en) 2009-02-27 2012-11-27 T-Mobile Usa, Inc. System and method for provisioning telecommunications services between an access point and a telecommunications network and providing a missing information notification
US8189548B2 (en) 2009-03-06 2012-05-29 T-Mobile Usa, Inc. Authorizing access to telecommunications networks for mobile devices, such as mobile devices accessing networks via non-traditional entry points
US8484457B2 (en) 2009-03-10 2013-07-09 T-Mobile Usa, Inc. Method of securely pairing devices with an access point for an IP-based wireless network
WO2011039784A2 (fr) * 2009-09-30 2011-04-07 Vinjamuri Venkata Ravindra Système et procédé d'authentification bimodale dans des réseaux hybrides

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2367213B (en) * 2000-09-22 2004-02-11 Roke Manor Research Access authentication system
AU2002212345A1 (en) * 2000-11-09 2002-05-21 International Business Machines Corporation Method and system for web-based cross-domain single-sign-on authentication
US7221935B2 (en) * 2002-02-28 2007-05-22 Telefonaktiebolaget Lm Ericsson (Publ) System, method and apparatus for federated single sign-on services
US7219154B2 (en) * 2002-12-31 2007-05-15 International Business Machines Corporation Method and system for consolidated sign-off in a heterogeneous federated environment
US8064891B2 (en) * 2003-10-24 2011-11-22 Telefonaktiebolaget L M Ericsson (Publ) Means and method for controlling service progression between different domains
WO2005064882A2 (fr) * 2003-12-29 2005-07-14 Telefonaktiebolaget Lm Ericsson (Publ) Moyens et procede pour acces par ouverture de session unique a un reseau de service, via un reseau d'acces

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006135285A2 *

Also Published As

Publication number Publication date
WO2006135285A2 (fr) 2006-12-21
WO2006135285A3 (fr) 2007-02-22

Similar Documents

Publication Publication Date Title
CN101720546B (zh) 通过ip多媒体子系统电信网络中的用户设备单元提供服务的方法,包括所述方法使用的用户数据库服务器、服务策略服务器和应用服务器
EP1880528B1 (fr) Prestation de services dans un systeme de communications
CA2532538C (fr) Appareil et procede d'authenfitication d'un utilisateur lorsqu'il accede a des services multimedia
US9503890B2 (en) Method and apparatus for delivering keying information
EP1563654B1 (fr) Equipement utilisateur adapte au protocole de signalisation sip permettant de fournir des services multimedia avec qualite de service
JP4713338B2 (ja) セルラ通信システムにおいて再認証を可能にする方法および装置
US7526296B1 (en) Telephone number allocation and management in a wireless access point
US9756499B2 (en) System and method for terminating communication sessions with roaming mobile devices
CN102474523B (zh) 用于发起在ip多媒体子系统网络的hss中对订户数据进行预配置的方法和装置
US20090076952A1 (en) Variable charging assignment for multi-service environments
EP1524816B1 (fr) Authentification de messages sur un système de communication
US20130091546A1 (en) Transmitting Authentication Information
EP3721648A1 (fr) Systèmes et procédés relatifs à l'attribution de services de réseau cellulaire
EP1891821A2 (fr) Procede et appareil de fourniture d'un service de telecommunications
Garcia-Martin Input 3rd-generation partnership project (3GPP) release 5 requirements on the session initiation protocol (SIP)
US20040243711A1 (en) Method, system and network element for controlling data transmission in a network environment
CN105409259A (zh) 通过wifi为非蜂窝设备提供电话服务
RU2337504C2 (ru) Устройство и способ для аутентификации пользователя при доступе к мультимедийным службам
CN100586110C (zh) 用于将消息路由到暂时不可利用的网络用户的方法、系统和网络设备
Poikselktä IMS Concepts
US20250039247A1 (en) Method, apparatus and computer program
CN1698308B (zh) 允许在蜂窝通信系统中重新认证的方法和装置
EP2040433B1 (fr) Mise à jour de mot de passe dans un système de communication
Garcia-Martin Rfc 4083: Input 3rd-generation partnership project (3gpp) release 5 requirements on the session initiation protocol (sip)
SB et al. „Diameter-based Protocol in the IP Multimedia Subsystem “

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070911

AK Designated contracting states

Kind code of ref document: A2

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

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20161005