DETAILED DESCRIPTION OF THE INVENTION

[0017] Preferred embodiments of the invention will be described using the following terminology. Since the term “network” is somewhat vague, the term “domain” will be used instead. A domain is one or more portions of a telecommunication system under a common administration. A subscriber's home domain (network) is the domain with the operator of which the subscriber has a subscription. Other domains are foreign domains. The term “network” will be used in connection with well-established terms like “network access” , “network address” or “network element”. In Mobile IP (Internet Protocol), the terms home agent-and foreign agent are frequently used. The term “attendant”, as used herein, is a close relative of a foreign agent known from the Mobile IP protocol (MIP). To be more precise, “foreign agent” is a term used in connection with the Mobile IP protocol, whereas “attendant” is commonly used in an AAA environment. An AAA attendant may constitute a part of a MIP foreign agent.

[0018] FIG. 1 illustrates a trust model according to the invention. A mobile node MN, whose home domain is HD, is going to register in a foreign domain FD. Each domain has an AM element or server. ‘AAA’ stands for authentication, authorization and accounting. The AM of the mobile node's home domain is called AAAH, and the one in the foreign domain is called AAAL. (In some documents, it is called AAAF, wherein ‘F’ means foreign, but AAAL appears to be more common.) That is, each AAA element acts as an AAAH to mobile nodes of its own domain and as an AAL to roaming mobile nodes. There is also an attendant ATT for assisting the mobile node's registration process. A possible location of the attendant is within a MIP (Mobile IP) foreign agent. The intervening network elements, such as radio stations and the like, have been omitted for clarity.

[0019] At the beginning of the registration process, the operator of the foreign domain FD cannot trust the mobile node MN, and the MN user cannot automatically trust the FD operator. But there is static (permanent) trust between the mobile node and its AAAH. Likewise, the foreign domain's AAAL has a static trust relationship to the attendant in the same FD. Between the domains HD and FD, a trust relationship can be negotiated, for example by exchanging digital certificates. In other words, there is a negotiable trust relationship between the HD and FD. A problem is that the mobile node cannot directly access its home domain (which it trusts) but only via the foreign domain's attendant, and there is a two-way lack of trust between the mobile node and the attendant. According to the invention, a dynamic trust relationship is established between the mobile node and the attendant, as will be shown in in more detail in connection with FIG. 3 . A dynamic trust relationship is a short-term trust relationship. It is typically negotiated via one or more third parties for the duration of one session.

[0020] FIG. 2 illustrates how the trust model can be mapped to concrete network elements. In FIG. 2 , there is a wireless local area network WLAN comprising three base stations BS. Each base station has an integrated attendant. There is an AAAL server serving the WLAN network and a filter/router F/R for communicating with external networks, one of which is the mobile node's home domain. The attendant extracts identification and authorization data sent by the mobile node and forwards them to the AAAL for verification. It is also responsible for configuring the filter/router F/R so that only authorized clients can access the network.

[0021] FIG. 3 is a signalling diagram illustrating a network access sequence according to a preferred embodiment of the invention. The procedure is based on a protocol referred to as Diameter, and it is specified in references [DIA base] and [DIA mobile]. The references are listed at the end of this description. The procedure shown in FIG. 3 comprises 10 actions and 9 messages. The actions are labelled A 1 through A 10 , and the messages are labelled M 1 through M 9 . This embodiment proposes changes to actions A 1 , A 2 , A 4 and A 10 and to messages M 1 , M 2 , M 3 , M 8 and M 9 . In FIG. 3 these actions and messages are shown in a bold typeface. The remaining actions and messages can be as specified in the Diameter references.

[0022] In action A 1 , a local AAA server AAL maintains a database (or table) of the services offered by it. The services are accompanied with other relevant parameters, for example cost, availability, etc. The AAAL is triggered to select periodically one or more services to be offered to mobile clients. After that, the AAAL prepares a service offering to be delivered for a mobile node or a group of mobile nodes.

[0023] Message M 1 comprises the actual service offering by the AAAL. The format and the delivery technique of the service offering are not essential for the invention. Possible delivery techniques include a router advertisement, an on-request reply and broadcasting over some control channel. Only the information contained in the service offering is important. A service offering should contain at least items 1 through 4 of the following list, and optionally items 5 and/or 6:

[0024] 1. SO_ID (=service offering identifier): A unique identifier of the service offering. The identifier serves to distinguish service offerings having the same origin.

[0025] 2. SO-PLD (service offering—payload): The payload or the actual service being offered. The format and contents are not essential for the invention. An example of a service offering payload will be described in connection with FIGS. 4 and 6 .

[0026] 3. FD-NAI (Foreign Domain—Network Access Identifier): Identifies the sender of the service offering in the foreign domain, preferably in the form of a Network Access Identifier (NAI), see [DIA Base]. A combination of a SO_ID and a FD-NAI is globally unique.

[0027] 4. ATT-ADDR (Attendant Address): Network or link level access information on how to contact an attendant that can accept a request for this service offering. This may be an IP address, MAC address or even a valid socket address for an application.

[0028] 5. VALID: An optional validity time indicating how long the service offering remains valid.

[0029] 6. SIG-FD: An optional digital signature signed by the sending AAAL. Any signature algorithm can be used. For example, the signature can be calculated over the remaining items 1 through 5 of the service offering message.

[0030] FIG. 4A illustrates how the above items can be sent in a service advertisement message. Field 41 is the service offering identifier SO_ID which will be used later to identify the service offering selected by the mobile node. Field 42 is the service offering payload SO_PLD which specifies the details of the actual offering, such as the tariff, bandwidth (speed), maximum delay, maximum error rate, etc. Fields 44 and 45 constitute network access information 43 which is basically the contents of a prior art service/router advertisement message. Field 46 is optional and indicates the validity time/period of the service offering. Field 47 is also optional. It is a digital signature computed over the remaining fields of message M 1 and signed with the private key of the foreign domain FD. By verifying this signature with the public key of the foreign domain, the mobile node may confirm the identity of the sender of message M 1 (in this case, the AAAL).

[0031] It is interesting to note that prior art service/router advertisement messages are routinely called “advertisement messages”. There is even a well-established session announcement protocol (SAP) that comprises such an advertisement message. But in the prior art, the service advertisement messages are used only to proclaim the existence of a network elements (a server or router). Prior art service advertisement messages have not been used to advertise services in the traditional meaning of the word “advertise”. At best, the prior art service advertisement messages perform brand advertising (“I am here”) but not detailed advertising (“I offer this QoS at that price”). In other words, a mobile node receiving prior art service advertisement messages from multiple foreign domains has no way of knowing which domain offers the best price/service ratio, such as the best price at a given quality of service (QoS) which is required for a given application. Alternatively, the mobile node may need to know which foreign domain offers the best QoS at a given price. Depending on the application type, the QoS may comprise factors like nominal bandwidth (data rate), minimum/maximum guaranteed bandwidth, packet delay and delay variability, guaranteed or worst-case error rate, packet loss probability, priority, etc. According to the invention, an advertisement message comprises not only an advertisement but an offer which is detailed enough to enable a meaningful comparison between service providers. A meaningful comparison requires not only knowledge of a service provider's existence (which is offered by the prior art service/router advertisement messages) but also price/tariff information and the quality of service to be delivered at the advertised price.

[0032] A traditional business model is that a client reacts to an advertisement by requesting a detailed offer, and the service provider responds to the request for offer by providing a detailed offer. The invention breaks this business model by sending a (sufficiently) detailed offer with the advertisement message, that is without an explicit request from the client.

[0033] FIG. 5 illustrates an example of a service request message M 2 . Field 51 is a mobile IP registration request, which is known from prior art. Fields 53 through 55 constitute the actual service request 52 which is related to requesting the service according to the service offering selected by the mobile node. Field 53 is a Mobile IP Network Access Identifier Extension for IPv4 (see RFC 2794). Field 54 is the mobile node's credentials, such as Mobile IP Challenge/Response Extensions (see RFC 3012). Field 55 identifies the service offering selected by the mobile node (or its user).

[0034] Reference is again made to FIG. 3 . Action 1 and message 1 can be repeated any number of times. FIG. 3 also shows service offerings from two additional AAAL servers, namely AAAL′ and AAAL″.

[0035] In action A 2 , a mobile node receives one or more service offerings from one or more sources in foreign domains. Based on user needs, the mobile node selects one service offering. Details of the selection mechanism are beyond the scope of this invention. For example, the selection can be based on factors such as the offered price, bandwidth, maximum delay, error rate, etc.

[0036] If the service offering comprises a digital signature, the mobile node can use the signature to verify the service offering before trusting its sender and selecting the service offering. For example, the mobile node may use a pre-defined key to check incoming service offerings with signatures. Alternatively, it can dynamically use some external public key infrastructure for obtaining the sender's public key.

[0037] Message M 2 comprises a service request (SR) from the mobile node. The mobile node constructs a service request on the basis of the information in the selected service offering. The MN then sends the SR to the attendant specified by the ATT-ADDR field of the service offering. Message M 2 must also contain the necessary information content specified in [DIA mobile]. One way to convey the SR to the attendant is to include a Mobile IP version 4 (MIPv4) mobile node registration request in a new message type. MIPv4 will be the default case from now on. A service request SR contains at least the following items:

[0038] 1. MN_NAI: The mobile node's Network Access Identifier. It identifies the mobile node (or its user) and its home domain, and home authority (AAAH).

[0039] 2. AAA_CRED: The AAA credentials (for example a signature of a challenge or a whole SR). AAA_CRED is the token which the AAAH uses to authenticate the mobile node or its user.

[0040] 3. SO_ID: The identifier of the selected service offering (see Message M 1 ).

[0041] The MN_NAI and AAA_CRED are required in the procedure specified in [DIA mobile]. By incorporating or attaching the SO_ID to the service request SR, the AAAL may begin resource allocation while the mobile node's home domain completes the authentication and authorization process. Also, there is no need to authorize the MN in respect of services it is not requesting.

[0042] In action A 3 , the attendant ATT processes the SR transparently. The ATT extracts the information from message M 2 as described in [DIA mobile] to construct a DIAMETER AMR (also described in [DIA mobile]). The attendant also includes the SR in the DIAMETER AMR as a new AVP (Attribute-Value Pair). According to the invention, the DIAMETER AMR also carries the mobile node's service request.

[0043] In message M 3 , the attendant ATT sends the newly-constructed DIAMETER AMR with the included SR to the local authority of the foreign domain. See [DIA mobile] for details.

[0044] In action A 4 , the AAAL checks the validity of the service offering and checks if the requested service can be supported. For user authentication and authorization, the AAAL relies on the home authority (AAAH) of the user like in [DIA mobile]. The checking step is relevant to the invention.

[0045] Messages M 4 through M 7 and actions A 5 through A 7 relate to authenticating the mobile node in its home domain. They are normal Diameter messages and actions, see [DIA mobile] for details.

[0046] Action A 4 can be performed in any one of three alternative places in the chain of events shown in FIG. 3 , namely before message M 4 , sometime between messages M 4 and M 7 or after message M 7 . Preferably, the AAAL performs action A 4 after sending message M 4 . This way, the AAAL can perform the checks in action A 4 while the home domain authenticates and authorizes the mobile node.

[0047] In action A 8 , the AAAL receives an AMA (AA-Mobile-Node-Answer) from the AAAH. The result of the authentication may be success or failure. In case the authentication is successful, message M 7 contains an MIPv4 registration reply (or MIPv6 binding reply). The AAAL constructs its own reply message M 8 which is a normal DIAMETER AMA appended with the information content of service indication (SI). Adding the SI to the registration reply is an essential feature of the invention. The service indication contains at least items 1 and 2 of the following list, and optionally items 3 and/or 4:

[0048] 1. SI_STATUS: The status, or answer, to the service request. It indicates success (0) or failure (any other value).

[0049] 2. FD-AUTH: A foreign domain authenticator. An example: the entire SI message signed with the MN-FD_key. A mobile node can verify this after recovering the MN-FD_key from the SI message.

[0050] 3. SI_INFO: additional information (optional). For example, in case of success, this field may contain link-level access information, an IP address and other configuration information from the AAAL. In case of failure, this field may contain a more detailed description of the reason of the failure.

[0051] 4. MN-FD_key: An optional session key to be used between the mobile node and the foreign domain. It should always be originated from the AAAH and encrypted by the MN-AAAH key.

[0052] If the authentication is successful, the AAAL sends message M 8 to the attendant. M 8 comprises a DIAMETER AMA with an included SI.

[0053] In action A 9 , the attendant obtains the session keys to be used for communicating with the mobile node (and the mobile node's home agent, in case MIPv4 is used). According to the service indication, the attendant grants resources to the mobile node. A simple implementation of resource granting is that the attendant merely allows the mobile node's traffic to pass the attendant from this moment on.

[0054] Message M 9 delivers the service indication to the mobile node.

[0055] Action A 10 completes the chain of events shown in FIG. 3 . The mobile node verifies the received service indication (if the optional signature is used) and the binding acknowledgement BA, and begins to use the offered service.

[0056] FIG. 6 is a signalling diagram illustrating a process in which a mobile node selects a service offering among the various service offerings sent by different mobile operators. Actions A 1 , A 2 , etc., and messages M 1 through M 9 shown in FIG. 6 are basically similar to the corresponding elements in FIG. 3 , the difference being that in FIG. 6 the emphasis is on the service offerings and service requests.

[0057] In the example shown in FIG. 6 , action A 1 comprises sending several service offerings SO# 1 through SO# 15 from two local AAA servers AAAL and AAAL′. The domain (network) addresses of the AAAL servers are xyz.com and foo.net, respectively. In FIG. 6 , the detailed service offering 42 has been divided into two fields 61 a and 61 b. Field 61 a indicates a price or tariff and field 61 b indicates the quality of service at the offered price or tariff. For example, a first service offering has an identifier SO# 1 , and it indicates a tariff of 15 (currency units) per megabyte and a maximum data rate of 1 megabit per second. As indicated by its field 46 , the service offering is valid for one hour. The remaining service offerings are constructed similarly, but identifiers SO# 6 and SO# 12 relate to offerings with a minute tariff instead of a megabyte tariff. All offerings SO# 1 through SO# 15 are collectively referred to as message M 1 and the act of sending them is collectively referred to as action A 1 .

[0058] In order to maintain the clarity of, FIG. 6 , the quality of service field 61 b comprises only one component, namely a nominal bandwidth. As stated earlier, the QoS may also comprise other components, such as a guaranteed bandwidth, packet delay and delay variability, guaranteed or worst-case error rate, packet loss probability, priority, etc. (In all radio traffic, however, “guaranteed” should be interpreted as “best-effort”.) Although all the example service offerings in FIG. 6 SO# 1 through SO# 15 relate to simple bearer (connectivity) services, the services to be offered can comprise more advanced services, such as a user's ability to create multicast sessions, etc.

[0059] In action A 2 , the mobile node MN receives and collects (at least temporarily) the service offerings having the identifiers SO# 1 through SO# 15 sent by different mobile operators. At this stage, the mobile node can either present the service offerings to its user and receive the user's selection, or it can perform the selection automatically, on the basis of some pre-stored criteria, such as the lowest tariff among the services meeting some minimum requirements (bandwidth, error rate, delay, delay variance, etc.) In this example, the mobile node or its user selects service offering 62 from xyz.com. Next the mobile node MN sends message M 2 to the attendant ATT. Message M 2 comprises a service request SR which in turn comprises the FD_NAI (xyz.com) of the AAAL, the identifier of the selected service offering (SO# 6 ), the MN user's network address in its home domain (john.doe@home.org) and the mobile node's (or its user's) AAA credentials which is a digital certificate. The attendant conveys the contents of message M 2 to the AAAL in message M 3 .

[0060] At this stage, the AAAL does not yet trust the mobile node MN. Therefore the AAAL sends the mobile node's credentials to the MN's home AAA server AAAH for authentication and authorization.

[0061] The fact that the mobile node MN receives and collects service offerings sent by different mobile operators has several alternative implementations. For example, the mobile node may collect service offerings until it appears to have all the available information; in other words, the MN receives repeated service offerings. After that, the MN or its user may select an optimal service offering. Alternatively, the mobile node may have a set of criteria for each application, such as a minimum bandwidth/maximum price, and as soon as a service offering fulfils the criteria, it is automatically selected. The actual selection process is not relevant to the invention. Also, the mobile node may select more than one service offering, such as one for voice calls and another for file downloads.

[0062] The above description is not tied to any specific protocol versions. Three different implementations with different protocols will be described next. The differences are limited to the over-the-air messages M 1 , M 2 and M 9 . The three different protocols are Mobile IP version 4 (MIPv4), Mobile IP version 6 (MIPv6) and AAA version 6 (AAAv6).

[0063] In a MIPv4 implementation, message M 1 can be transported in an ICMP (Internet Control Message Protocol) Router Advertisement. M 1 may appear with a Mobility Agent Advertisement Extension [RFC 2002, 2.1.1]. The service offering identifier SO_ID and the service offering payload SO_PLD (fields 41 and 42 in FIG. 4 ) can be implemented as new extensions to ICMP Router Advertisements. The Foreign Domain Network Access Identifier FD_NAI (field 44 ) can be implemented as a generalized NAI Extension. For an implementation of a NAI extension, reference is made to [AA]. The attendant address ATT_ADDR, validity period VALID and the foreign domain signature FD_SIG (fields 45 , 46 and 47 ) can be implemented as new extensions to ICMP Router Advertisements.

[0064] Message M 2 can be transported in a MIPv4 registration request. The actual registration request (field 51 in FIG. 5 ) can be a plain MIPv4 registration request header, see [RFC 2002]. The MN's Network Access ID MN_NAI (field 53 ) can be as disclosed in [RFC 2794]. The MN's credentials AM_CRED (field 54 ) can be as disclosed in [RFC 3012]. The service offering identifier SO_ID (field 55 ) can be a new extension to [RFC 2002]. Finally, message M 9 may be an MIPv4 registration reply appended with a new extension to support service indication (SI).

[0065] In an MIPv6 implementation, message M 1 can be transported in an IPv6 Neighbour discovery message, see [RFC 2461]. M 1 may appear with a modified Router Advertisement Message, see [MIPv6]. The service offering identifier SO_ID and the service offering payload SO_PLD (fields 41 and 42 in FIG. 4 ) can be implemented as new extensions to ICMPv6 Router Advertisements. The Foreign Domain Network Access Identifier FD_NAI (field 44 ) can be implemented as a generalized NAI Extension. The attendant address ATT_ADDR, validity period VALID and the foreign domain signature FD_SIG (fields 45 , 46 and 47 ) can be implemented as new extensions to ICMPv6 Router Advertisements.

[0066] Message M 2 can be transported in a MIPv6 registration request. The actual registration request (field 51 in FIG. 5 ) can be a plain MIPv6 registration request header, see [MIPv6]. The MN's Network Access ID MN_NAI (field 53 ) can be carried as a client identifier option, see [AAA]. The MN's credentials AAA_CRED (field 54 ) can be carried as a Security Data option, see [AM]. The service offering identifier SO_ID (field 55 ) can be a new option. Message M 2 thus requires a new option in addition to a binding update (BU) option. Finally, message M 9 may be an MIPv6 registration reply appended with a new extension to support SI.

[0067] The AAAv6 specifications do not list any specific ways of transporting message M 1 , but it can be transported in one of at least three ways, namely 1) in a MIPv4 router advertisement (in an MIPv4 implementation), 2) in a MIPv6 router advertisement option plus a new extension (MIPv4 implementation), or 3) as a new ICMPv6 message). All of the above fields 41 , 42 and 44 through 47 can be implemented as new options to AAAv6. Message M 2 can be transported in a MIPv6 registration request. The actual registration request (field 51 in FIG. 5 ) can be a plain MIPv6 registration request header, see [RFC 2002]. The MN's Network Access ID MN_NAI (field 53 ) can be carried as a client identifier option, see [AAA]. The MN's credentials AM_CRED (field 54 ) can be carried as a Security Data option, see [AAA]. The service offering identifier SO_ID (field 55 ) can be a new option. Finally, message M 9 may be an MIPv6 registration reply appended with a new extension to support SI.

[0068] In some cases, message M 1 can be described in session description protocol (SDP) and carried to the end user via session announcement protocol (SAP). In such cases, the service is most likely a multicast session. If the SDP protocol is extended, it will be possible to describe more abstract services.

[0069] Although the invention has been described in connection with some specific embodiments, it is not limited to these examples but it can be varied within the scope of the appended claims.

References

[0070] [AAA]: AAA for IPv6 Network Access, Internet draft by Charles E. Perkins et al. (“draft-perkins-aaav6-02.txt”)

[0071] [DIA base]: Diameter Base protocol, Internet draft by Pat R. Calhoun et al. (“draft-calhoun-diameter-17.txt”)

[0072] [DIA mobile]: Diameter Mobile-IP Extensions, Internet draft by Pat R. Calhoun et al. (“draft-calhoun-diameter-mobileip-11.txt”)

[0073] [MIPv6]: www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txt

[0074] The above Internet drafts and RFC 2002, 2461, 2794 and 3012 can be found at address http://search.ietf.org/internet-drafts

[0075] All references are incorporated herein by reference.

Acronyms (some are not Official)

[0076] AA: Authentication & Authorization

[0077] AAA: Authentication, Authorization and Accounting

[0078] AMH: an AM server in a mobile node's home domain

[0079] AAAL: a local AAA server, also called AAAF (F=foreign)

[0080] AMA/AMR: M Mobile node Answer/Request

[0081] AVP: Attribute-Value Pair

[0082] BA: Binding Acknowledgement

[0083] BU: Binding Update

[0084] FD: Foreign domain

[0085] HAR: Home-Agent-MIP-Request

[0086] HD: Home domain

[0087] ICMP: Internet Control Message Protocol

[0088] MIP: Mobile IP

[0089] MN: Mobile Node

[0090] MN-FD_key: a key used between a mobile node and a foreign domain

[0091] NAI: Network Access Identifier

[0092] SAP: Session Announcement Protocol

[0093] SI: Service Indication

[0094] SIG_FD: a packet digitally signed by the private key of a FD (an AAAL)

[0095] SO: Service Offering

[0096] SR: Service Request