WO2004077754A1 - Ｗｌａｎ相互接続におけるサービス及びアドレス管理システム及び方法 - Google Patents

Ｗｌａｎ相互接続におけるサービス及びアドレス管理システム及び方法 Download PDF

Info

Publication number
WO2004077754A1
WO2004077754A1 PCT/JP2004/000176 JP2004000176W WO2004077754A1 WO 2004077754 A1 WO2004077754 A1 WO 2004077754A1 JP 2004000176 W JP2004000176 W JP 2004000176W WO 2004077754 A1 WO2004077754 A1 WO 2004077754A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
mobile terminal
address
tunnel
information
Prior art date
Application number
PCT/JP2004/000176
Other languages
English (en)
French (fr)
Inventor
Pek-Yew Tan
Hong Cheng
Bing Tan Chee
Original Assignee
Matsushita Electric Industrial Co., Ltd.
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 Matsushita Electric Industrial Co., Ltd. filed Critical Matsushita Electric Industrial Co., Ltd.
Priority to EP04702063A priority Critical patent/EP1585270A4/en
Priority to CA2512959A priority patent/CA2512959C/en
Priority to US10/541,447 priority patent/US7610038B2/en
Publication of WO2004077754A1 publication Critical patent/WO2004077754A1/ja
Priority to US12/559,468 priority patent/US8081971B2/en
Priority to US13/292,874 priority patent/US8374580B2/en
Priority to US13/737,366 priority patent/US9055563B2/en
Priority to US14/707,308 priority patent/US9560521B2/en
Priority to US15/409,914 priority patent/US9986426B2/en
Priority to US15/961,951 priority patent/US10511961B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5084—Providing for device mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the invention relates to the field of wireless data communication. More particularly, the present invention relates to address management for mobiles and users visiting from other networks in a wireless LAN (WLAN) environment, wherein the WLAN resides, for example, in a separate administrative domain, and It can be used for inter-networking with public wireless networks such as 3G networks and WLANs that use wireless technology.
  • WLAN wireless LAN
  • the present invention can also be used by mobile terminals in addition to WLANs and inter-worked networks for address allocation, configuration, tunneling settings, etc.
  • Mobile terminal is a service subscribed in WLAN
  • a terminal In WLAN interworking, a terminal must not be addressable so that it can access all the services to which it has subscribed. If the service is transmitted over IP, the terminal must be associated with an IP address. In the mopil world, the point of attachment of a terminal changes frequently, and it is quite possible that the terminal will roam across several domains during an active service 'session. To meet this mobility requirement, the address management mechanism requires that the terminal address be configured and updated each time the terminal changes its point of attachment.
  • Mopile IP is a standardized technology published by the Internet Engineering Task Force (IETF) (Non-Patent Document 1) (Non-Patent Document 2), and a solution to address management and traffic routing for mobile terminals. I will provide a.
  • This technique allows users to be located while using the same address when moving around in various IP networks. Because mobility is managed at the IP level, mobile IP is not tied to the underlying link-layer technology and can be used for 3G cellular 'networks, or wireless LANs (e.g., The same protocol and stack can be applied to the terminals in (h). This type of harmonized level solution is particularly useful, for example, in the fusion of access technologies, such as the interconnection of a WLAN with a 3G cellular network.
  • address management is performed by IP connection, and if IP connection is not available, address management becomes impossible.
  • terminals need to have a home 'address and know the home' agent. These requirements may not be met during the operation of the interconnect, for example, when a terminal first starts operating in a foreign WLAN.
  • the draft of Mopile IPV 6 introduces a method of setting the home address of a mobile node (Non-patent document 2).
  • the terminal first generates a care-of address (Care of address) using, for example, DHC PV 6 (Non-Patent Document 3), and sets a final home address using this address.
  • Home '' Communicate with the network.
  • the care-of address obtained from the WLAN is used, the mobile node's home 'network is not always in a state where the mobile node can be located. Become.
  • a configuration process that performs multiple interactions Is time consuming and does not meet user expectations.
  • Non-Patent Document 4 a solution for address management of the mopile IPV 6 based on the configuration of the AAA is shown by the application of the parameter “Mopile IPv6” (Non-Patent Document 4).
  • This solution relies on the AAA server and the clients on the destination and 'home' networks to perform address updates and agent discovery.
  • the mechanism requires that the mobile node have a local IP connection for exchanging messages, e.g., to be able to listen to router advertisements' messages. Is not always possible.
  • this mechanism is only provided in situations where the address belongs to the mobile terminal's home domain.
  • the terminal uses an address from another domain that depends on the service that the terminal is accessing, and since this address does not have information about the terminal's service 'request, this mechanism Cannot support WLAN interconnect.
  • This mechanism is designed for the Mopile IP V6 environment and therefore cannot operate on terminals without the Mopile IP stack.
  • GTP Non-Patent Document 5
  • GTP-C for control
  • GTP-U for user's data traffic
  • GTP runs over UDP and encapsulates user's data in UDP packets.
  • This GTP is designed for GPRS (Non-Patent Document 6) networks and relies heavily on the features of GPRS networks, for example, GGSN, S GSN nodes, etc.
  • Network for example,
  • Non-Patent Document 13 Numbering, addressing and identification
  • Non-Patent Document 14 Port'Based Network Access Control '' IEEE Std 802.1X-2001 http://standards.ieee.org/getieee802/
  • Non-Patent Document 15 Diameter Extensible Authentication Protocol (EAP) ApplicationJ
  • Non-Patent Document 1 7 ⁇ IPv6 Stateless Address AutoconfigurationJ http : //www.ietf.org/rfc/rfc2462.txt
  • the W LAN and the interconnecting network are in different administrative domains. This means that the address space is managed separately. Therefore, when a mobile terminal moves to a WLAN in a domain different from its home 'network, some address configuration must be performed to guarantee continuous service delivery to the terminal.
  • This address configuration includes, for example, IP address assignment, address registration, and tunneling settings.
  • Addresses are limited in order for any service to be delivered to terminals via WLAN.
  • IMS Non-Patent Document 7
  • the terminal needs to have an address belonging to the network that provides the IMS. Yes, and consequently, mobile terminals with parallel access to different services are required to be assigned multiple IP addresses.
  • the terminal Under WLAN, the terminal is not allowed to use any resources, for example, sending and receiving normal data packets, before authentication and its authorization are given.
  • the usual mechanism, such as suggested in MIPV 6, is that address configuration occurs only after successful authorization processing, but this type of approach is time consuming and may meet the requirements for some services. Can not.
  • information related to the address configuration needs to be integrated into the access control message.
  • address management is usually based on user subscription information and must be managed by the mobile terminal's home network. However, any external services need to be assigned an address from a domain other than the Home 'network. In this case, a mechanism is needed for the home network to exchange address assignments and other information in the domain.
  • the end-to-end (QoS) QoS associated with that terminal will be affected. For example, if the address changes, a traffic filter based on source or destination address information will not be able to accurately classify the flow. For WLANs that implement firewalls and other traffic control functions, the new address of the terminal must also be indicated, otherwise traffic may be blocked or interrupted. Become. Disclosure of the invention When a terminal enters the WLAN, the terminal must complete the authentication and authorization processes to gain access to resources.
  • the present invention provides a solution to address management that is integrated into the access control mechanism. This integration makes it possible to assign terminal addresses at the same time as access is granted. Also, the terminal reuses and extends the access control mechanism, so there is no need to implement a new protocol.
  • the address configuration process is protected by the inherent encryption and protection of the access control process and therefore does not require any special security settings.
  • the present invention further provides a means for the home network of the terminal to negotiate an address management with a network for providing the service of the terminal.
  • This type of interaction is a back 'end' process, transparent to the mobile terminal and the WLAN, and the result of the agreement is to use the service authorization process to communicate to the WLAN and the mobile terminal. Will be sent.
  • the present invention provides a method for a terminal to obtain an address associated with a session using a fine-grained service authorization process. Each session uses the associated address to migrate to the new address.
  • Policy 'control provides a means for configuring the WLAN on the terminal and its home network, if necessary, after the address has changed.
  • QoS or tunneling information is modified and provided according to the new status using the channels available in the existing policy control process. This allows roaming Within time, a smooth transition of addresses can be achieved, and the interruption of QoS can be minimized.
  • FIG. 1 is a block diagram showing an example of a network configuration used for assigning addresses of mobile terminals, setting up tunnels, and managing service agreements in the WLAN interconnect according to the present invention.
  • Figure 2 shows the messages used to assign terminal addresses, set up tunnels, and negotiate services used in the configuration shown in Figure 1.
  • Sequence 'chart showing an example of a sequence
  • FIG. 3 is a data structure diagram showing one embodiment of a message structure used by a mobile terminal in the message exchange shown in FIG. 2,
  • FIG. 4 is a data structure diagram showing an example of a format used by a mobile terminal for an address assignment request
  • FIG. 5 is a state transition diagram showing an embodiment of a home network authorizer in the framework shown in FIG. 1 for assigning addresses of mobile terminals, setting tunnels, and arranging services in WLAN interconnection.
  • FIG. 6 is a flow chart illustrating an example of a flow chart that may be used to perform a request message processing procedure at a home network authorizer.
  • Figure 7 shows the structure of the message used by the home 'network' authorizer to negotiate service details, address assignments, and tunnel settings for the service provider's network.
  • Figure 8 shows the details of the WLAN server and mobile terminal services, Data structure diagram showing one embodiment of the structure of the message used by the home's network.
  • Figure 9 is a data structure diagram showing one embodiment of a message structure used by the Home Network Authorizer to update the state of the mobile terminal of the Policy Server in the Home 'network domain. It is. BEST MODE FOR CARRYING OUT THE INVENTION
  • the present invention is used by WLANS to inter-work with other networks.
  • As the interconnected network another WLAN or a public cellular network can be used, and in either case, the present invention can be easily applied. Further, the present invention is used for the purpose of performing address management and providing services related to address transition (ie, mobility control).
  • a terminal When a terminal enters WLAN, it is authenticated and authorized before being allowed to use the service. In the authorization procedure, the terminal requests the service to be accessed and this information is passed to the terminal's home 'network through WLAN. The terminal's home 'network decides whether to allow the service based on the user's subscriber profile. In addition, depending on the service requested, the terminal's home network determines the address used for the service. For example, for the IMS service, the address needs to be allocated from the IMS address space, while for the local WLAN service, the address obtained locally is sufficient. In addition, information on tunneling related to address management is confirmed.
  • the address information is included in the permission information and is sent with the permission success message. Some of this information is sent to WLAN and some is sent to the terminal, as in normal authorization procedures. For example, an address needs to be sent to a terminal so that the terminal can configure its own address configuration. Also, if network tunneling is required, the tunnel information is used by WLAN.
  • policy-control is started.
  • the address information is made available by the terminal's home's network's policy server, after which the policy server can make policy decisions based on the address information.
  • the policy server is notified of the corresponding address. Notification is provided to update the policy, which guarantees QoS and service delivery.
  • WLAN refers to a wireless local 'area' network, which includes any number of devices that provide LAN services to mobile terminals via wireless technology.
  • 3G network refers to a third-generation public access network, for example, defined by 3GPP (Non-Patent Document 10) and 3GPP 2 (Non-Patent Document 11). System.
  • Mobile terminal refers to the equipment used to access services provided by WLANs and other networks via wireless technology
  • Home.network refers to the network in which the service subscription information of mobile terminals (MTs) is stored.
  • MTs mobile terminals
  • the network to which MT first subscribed or the MT subscription Visited network that has full access to the information.
  • Service 'Provider' network refers to the network in which the service requested by the MT is provided, and can be any network, for example, home network, WLAN, external network, etc. is there.
  • Network 'element refers to any device functioning in a network that can execute information processing.
  • a “policy server” refers to a network element that performs the policy control functions of a network domain. Policy 'control functions include, for example, local resource allocation, packet' filter updates, and routing updates.
  • Air interface refers to any wireless access technology that allows a mobile terminal to access a WLAN.
  • a “stream” is a group of packets transmitted in a network that has certain attributes in common.
  • Traffic is a collection of streams transmitted within a network.
  • Flow refers to the data 'path and network resources required for the data path used to carry the stream.
  • QoS is the quality of service of the data stream or traffic.
  • Message refers to information exchanged between network elements to control the interconnection.
  • An “operation sequence” refers to a series of message exchanges between any network 'elements for the purpose of interconnected control.
  • the “upper layer” refers to any entity that exists above the current entity and processes the bucket passed by the current entity.
  • “Client-based tunnel” refers to a tunneling mechanism where one of the tunnel endpoints is a mobile terminal.
  • Network-based tunnel refers to a tunneling mechanism in which the endpoint of the tunnel exists in a network element other than the mobile terminal.
  • Mobility 'control is one of the most prominent issues in WLAN interconnects due to the high mobility of the terminals. If the terminal moves, the terminal is required to use a non-local address for the point of attachment. For example, for a 3G terminal that has entered a WLAN, a 3G domain address is required to access its home 'network services (eg, IMS services). When the terminal starts a service in the 3G network, an address is allocated according to a 3G scheme such as, for example, a GPRS service (Non-Patent Document 6), and the address is assigned to the 3G network of the terminal. Associated with Cellular 'interface. Also, when a terminal enters a WLAN domain, high throughput can be realized, and it is desirable to communicate using the WLAN interface.
  • a 3G scheme such as, for example, a GPRS service (Non-Patent Document 6)
  • a PDA with a dual interface uses a GPRS interface on the road and an IEEE802.1 in the hot spot. It is desirable to use one interface. If the terminal accesses 3G services using the WLAN interface, the terminal must continue to use the same address as obtained from the 3G interface. Otherwise, the terminal will experience service interruption and have to re-initialize the session, which is not desirable for the user. Also, since the address in use is not local to the WAN, the tunnel must be set up from the terminal to the service provider network.
  • FIG. 1 shows an embodiment of the present invention for address assignment and tunnel setup. Note that only network entities participating in the signaling are shown to avoid confusion.
  • the mobile terminal (101) is an entity that requests a certain service from the network. In practice, it is possible to have several entities, for example a handset connected to a laptop computer via a Bluetooth link, but for simplicity, only one set is shown in Figure 1. It is drawn as G.
  • the access point (105) is the entity that provides WLAN access to the mobile terminal (101).
  • the access point (105) blocks all data traffic from the mobile terminal (101) until the mobile terminal (101) is given permission to use the WLAN service. However, a controller / channel that allows only a specific data bucket is opened for access / controller signaling.
  • the mobile terminal (101) communicates with the access point (105) via a wireless link (1011).
  • This link can use any type of wireless technology, including, for example, IEEE 802.11.1, HiperLAN / 2, infrared, etc., and similar access control technologies can be applied In other cases, other technologies such as fiber optics may be used on this link.
  • the WLAN management server (WLAN server) (102) exists as another entity in the WLAN.
  • This WLAN server (102) is in charge of address space management and WLAN resource management.
  • the power existing on the WLAN gateway and the access point (105) for a simple WLAN are shared. It is established.
  • WLAN server (102) is interface (101) Communication with the access point (105) via. This is for WLAN resources' control and service provision, for example, QoS management via the air interface.
  • the server can also interact with other entities of the WLAN, such as a WLAN firewall (not shown).
  • a home' network authorizer (103) manages service authorization and address assignment.
  • the access point (105) and the WAN server (102) are both connected to the home network to obtain service control information via link (1012) and link (10114). 'Communicate with the respective software (103).
  • the link (1012) and the link (1004) can be the same, that is, the same protocol is used, and the same terminal is used for the same terminal. Even when encapsulated in packets, they are logically separated.
  • the mobile terminal (101) can request all services to which it has subscribed. These services are available in the home's network (
  • the service 1002) may be in a separate service provider's network (1003), or the WLAN itself. If the service is provided by the home's network (1002) or the WLAN, the service provider's network (1003) will overlap with these networks and the controller Can be associated with both functions.
  • the service 'provider' network management server (service 'provider' network server) (104) is used for service authorization and service 'provider' network (1003). Manage address allocation.
  • the home 'network' authorizer (103) communicates with the service provider 'network' server (104) via the control 'interface (101-3). In practice, it is possible to use a WLAN, a home 'network (1002) or another network as the service' provider network (1003). Also, if the service is provided on the home 'network (1002), this interface will be an internal interface, with the exact format and the same protocol as described in the examples below. You don't need to use
  • FIG. 2 shows an example of an Operation 'sequence for address management of a WLAN interconnect using the above framework.
  • the mobile terminal (MT) (101) has already completed the WLAN association and authentication procedure (201).
  • the mobile terminal (101) and the access point (105) have mutually authenticated each other, and are already protected by encryption for the subsequent message exchange.
  • the mobile terminal (101) wants to access any service via WLAN, it sends an MT_Request_A message (202A) to the access point (105) via the link (101).
  • the message is delivered to Home 'Network Authorizer (103). This message is protected end-to-end (end-to-end) with a key generated from the authentication procedure (201).
  • FIG. 3 shows an embodiment of the message MT_Request_A message (202A).
  • the message starts with the Message—Type field (301). This field identifies what type of message is encapsulated, for example, request, reply, and so on. The length of this field is 1 octet And the message type is represented by an integer number. This saves limited resources for signaling over the air interface. It should be apparent to those skilled in the art that other formats can be used if necessary.
  • the Message—Type field (301) is the Message—Length field (302). It contains information about the length of the entire message, including the Message_Type field (301).
  • the next field is the Domain_Name field (303). This field identifies the home 'domain of the mobile terminal (101). It is also possible to use a Network Access Identifier (NAI) (Non-Patent Document 1 2).
  • NAI Network Access Identifier
  • the UserlD part before the “@” symbol uses a wildcard value, for example “roamed”.
  • the home 'domain information is used to route messages to the mobile terminal (101)' s home 'network authorizer (103).
  • Message-Type field (3 0 1)
  • Message-Length field (3 02)
  • Domain-Name field (303)
  • Domain The field following the Name field (303) is protected by a security association between the mobile terminal (101) and the Home 'Network Authorizer (103). For example, this could be the public key of the home 'network' authorizer (103), that is, the session 'key originating from the authentication procedure (201), and also the message protection. It is also possible to use the UserID part of the Domain-Name field (303) to indicate the index of the key used for
  • This field contains information that uniquely identifies the mobile terminal (101) in the context of the home 'network (1002). This can be, for example, the IMSI (Non-patent Document 13) of the mobile terminal (101) or the TMS I (Non-patent Document 13) obtained in the authentication procedure.
  • Home 'Network Authorizer (103) uses this identifier to retrieve the user's subscription information. It is obvious to those skilled in the art that other formats can be used in this field, as long as the home 'network authorizer (103) can map it to the actual user identity. It is.
  • the next field is the Service—Request field (305).
  • This field is used by the mobile terminal (101) to indicate the services that it wants to access the home 'network' authorizer (103). Since the message is between the mobile terminal (101) and its home network authorizer (103), it is specific to the particular operator and network. For example, in a 3GPP network, this could be the GGSN to use and the APN to identify the particular service to access (NPL 13). It will be apparent to those skilled in the art that other formats can be used if the home 'network (1002) is another type. It is. Further, it is also possible to add other service request information, for example, a bandwidth request. Available values for the field may be "2M. Bandwidth. Request. IMS.ioo. Bar.
  • the mobile terminal (101) can obtain information about the format from the SIM or USIM card.
  • the Session ID field (306) provides session control information. This is used to identify that the request for this service is a session associated with the Home Network Authorizer (103).
  • the session identifier should be locally unique within the mobile terminal (101), and the mobile terminal (101) should maintain a local record of all service sessions. Whenever a new service session starts, a new entry with a new session identifier is created, and when the session ends, the entry is deleted and the identifier is released and reusable. Become.
  • the field is 2 octets, and the identifier is a hexadecimal value. It should be apparent to those skilled in the art that other types of identifiers supported by the terminal can be used.
  • the MT-ID field (304) and the Session-ID field (306) uniquely identify the service 'session in the home network' authorizer '(103).
  • the Address-Request field (307) contains information on an address allocation request from the mobile terminal (101).
  • This embodiment Uses a composite structure, as shown in Figure 4.
  • the first part of this structure is the Address-Type field (401). This identifies which type of address is supported by the mobile terminal (101).
  • the size of this field is 1 octet and possible values are:
  • No_IP :: 0x00
  • Dual_Stack_IPv6_Preferred_FullAddress :: 0x05;
  • Suggestion—Length field (402) This field indicates the length of the next field, Address—Suggestions field (403).
  • the Addi'ess_Suggestions field (403) lists the addresses that the mobile terminal (101) wants to be assigned. For example, if an ongoing session is using an address, it is important that the same address be assigned so that the session is not interrupted. For example, Address—Suggestions Fino Red (403) is a list of addresses. Each entry in the list begins with a one-octet type, indicating the type of address, for example, IPv4 or IPv6, followed by the actual address. In the home network authorizer (103), which does not support the feature of address presentation by the terminal, the Suggestion—Length field (402) and the The Address—Suggestions field (4 0 3) is silently ignored.
  • Tunnel—Request field (308) is present. This field is used by the mobile terminal (101) to indicate which type of tunnel is supported. The first octet of this field indicates the length of this field, including itself, and the contents of this field are
  • each entry may be a list with each entry occupying Otatetsu DOO includes a tunnel type identifier mobile terminal (1 0 1) is supported, the octet
  • the value of the default can be:
  • the second octet of each entry indicates the direction of the tunnel. What are the possible values of this octet? It is as follows.
  • Tunnel-Terminal strength :: 0x01;
  • Tonnore-Bidirectional : 2 0x03;
  • the first entry in the list indicates the preferred type of mobile terminal (101).
  • the next field in the MT—Request_A message (202 A) is the WLAN—ID field (309). It contains information that identifies the WLAN to the Home 'Network Authorizer (103) so that the Home' Network Authorizer (103) can make location-based decisions. Or provide services based on the location of the mobile terminal (101).
  • the WLAN_ID can be obtained from the authentication procedure and information broadcast from an access point (105) such as an SSID in an IEEE 802 network. It also contains the local identifier of the mobile terminal (101). This is for the access point (105) to identify the terminal.
  • the last field is Security—Field (3 1 0). This field contains information that protects the message.
  • the exact algorithm used for this field is negotiated between the mobile terminal (101) and its home 'network' authorizer (103). It may also be determined by the user's subscription time and stored on the terminal's SIM or USIM card. It can also be implemented as a software-to-air module, which can be down-loaded whenever necessary.
  • the EA defined in IEEE 802.1x It can be realized as an EAP message using POL (Non-Patent Document 14).
  • the access 'point (105) receives this message, it will derive the home' domain information from the Domain-Name field (303) and use that domain information, for example, by querying the DNS. It is possible to obtain the address of the Home 'Network Authorizer (103).
  • the Access 'Point (105) forwards the message to the corresponding Home' Network Authorizer (103) according to this information. For example, if the WLAN has a central AAA server, the access point (105) forwards the message directly to the AAA server.
  • the AAA server in the WAN parses the domain information and forwards the message to the actual home network authorizer (103). It is assumed that there is a secure link between the Access 'Point (105) and the Home' Network Authorizer (103). ), Or by dynamically setting the security associations derived from the process.
  • the access point (105) does not need to participate in message processing, and therefore does not need to perform the entire stack to parse the message. It simply reads the message 'type
  • the protocol used for the transfer may be any suitable AAA protocol (for example, an EAP application for a parameter (Non-Patent Document 15) or a NA SREQ application for a parameter (Non-Patent References 16))) are possible. These protocols provide access- It is already available at point (105).
  • the message MT—Request—A message (202 A) is essentially a message from the mobile terminal (101) to the home network authorizer, similar to the end-to-end authentication procedure (201). Sent at (103) end 'to' end.
  • FIG. 5 shows an embodiment of the state machine of the home network authorizer (103).
  • Home 'The network authorizer (103) starts from the initial state (501), performs initialization 0 at the transition (/ intiateO) (5001), and performs the idle state (5002). Move to).
  • the initialization 0 process includes all the steps required to establish connections with other packend 'servers, establish security associations, and so on. In fact, it will be apparent to those skilled in the art that other processes may be involved depending on the configuration.
  • FIG. 6 shows an embodiment of the message decryption state (503).
  • the home network authorizer (103) uses the key identified by the Domain_Name field (303) in step (6001) to
  • the Home Network Authorizer (103) retrieves the user's subscription information from its database and back-end server (for example, the HSPS in a 3GPP network). .
  • the home network authorizer (103) analyzes the service request information obtained from the Service-Request field (305).
  • the service request can include various service-specific information to be inserted, such as, for example, bandwidth, delay, instability.
  • step (6005) within the Home 'Network Authorizer (103), a determination is made as to whether the user should remain unserviced using the user subscription information. If, based on the user's subscription, the requested service should not be granted, the home network 'authorizer' (103) sets in step (60 13) a flag that denies the service, The state machine transitions to the denial of service state (504) at transition (5004).
  • step (600) from the Address-Request field (307), the Ho 'Network' software (103) sends the address that the mobile terminal (101) wants to use. Get the dress. Note that if you do not want to support this feature due to the home network 'authorizer (103) power, operator's policy, or other, you can silently ignore this information.
  • the mobile terminal (101) should always use the final address assigned by the home network authorizer (103).
  • the home's network authorizer (103) may determine from the requested service whether the address should be assigned locally or within the home-network (1002) or the service provider's network. Determine if it should be allocated within (1003). For example, if the user is only allowed to use the WLAN local 'service, the address will be allocated within the WLAN, while users subscribing to the VPN service will use the address in that VPN. Should be assigned.
  • the home 'network' authorizer (103) searches the Tunnel—Request field (308) in step (610) for the type of tunnel supported by the mobile terminal (101). I do. This information is used to set up the tunnel for service provision.
  • the mobile terminal (101) enumerates one or more tunnel types and lists The first of them can be of the preferred type.
  • the home network authorizer (103) needs to check with the service provider's network server (104) to determine which type to use. Note that, for example, additional information such as the direction of the tunnel may be included.
  • the home's network authorizer (103) determines from the WLAN ID field (309) that the mobile terminal (101) is currently involved in the wireless LAN. Obtain identification information. Using this information, the home network authorizer (103) finds the corresponding WRAN management server (102). As part of the roaming agreement, this information can be stored in the database of the home 'network' authorizer (103), and can be stored by the backend 'server (eg, HS S). Can be extracted. After obtaining the server information, a secure link is established. This link is used for subsequent service 'message' signaling.
  • the backend 'server eg, HS S
  • the home 'network' authorizer (103) After obtaining all the information, the home 'network' authorizer (103) creates the Service—Reqeust message (203) and 1 ⁇ 1 ⁇ -13 ⁇ 4 (111 ⁇ 28 message (205), This message is sent when the state machine of the network 'authorizer' (103) transitions to the standby state (504).
  • FIG. 7 shows an embodiment of the Service-Request message (203).
  • This message begins with the Home—Network—ID field (701).
  • This field contains information about the home's network identifier of the mobile terminal (101) and can be the operator's name or a large network subsystem. Identifier must be globally unique
  • the DNS name of the network for example “network.operator.3gpp.org”, is a good candidate for this identifier.
  • the presence of the home network information allows the service 'provider network' server (104) to apply network policies, such as roaming agreements, to service requests.
  • the user's profile is managed by the Home 'network (1002).
  • user information should not be sent to the service provider's network server (104), but add user.priority / grouping information to the message to allow better control of the service. It is also possible. This, for example, "goldmember. Network. Operator.3gpp.orgJ Donoyotsu (this may be associated with a home 'waving network identifier. Service provider. Network. Server (1 0 4), this Using, it is possible to differentiate users when providing services.
  • the next field is the MT-ID field (702).
  • This field contains information about the identity of the mobile terminal (101) and is used by the Home's Network Authorizer (103) to perform service tracking.
  • the identifier may be assigned by the terminal's IMSI or the home 'network' authorizer (103) and may be a temporary ID unique to the service 'session. This information needs to be consistent until the service 'session ends.
  • Session_ID field (703) This is the session identifier assigned by the terminal.
  • the service 'provider' network 'server (104) should maintain a record of all current session information.
  • the session identifier exists in the database, Means that the service request is triggered by a handover and that the same address configuration should be used to avoid service interruption. For example, if a session is active (active), the service provider network server (104) should assign the same address to the mobile terminal (101). As a result, communication with the correspondent node can be continued without signaling.
  • This part indicates the type of address to be assigned, eg, IPV6, in Service Provider-Network Sanoku (104). Furthermore,
  • MT-Request Provides the address requested by the mobile terminal (101), as well as the Address_Request field (307) of the A message (202A). This information can be ignored if the service 'provider' 'network' server (104) does not want to support this function. This field may also be used if the home 'network' age-solitizer (103) determines that it does not need to be assigned an address from the service 'provider' network (103). May be omitted.
  • the Service—Spec field (705) is a compound field that contains information about the specific requirements required by the Home's Network Authorizer (103) based on the user's subscription information.
  • a possible implementation of this field (data structure 1) is shown below.
  • bitrate-avg and bitrate-max are the bit rate that guarantees the requested service and the maximum bit rate.
  • the deliver-order attribute indicates whether delivery is performed in order.
  • the MTU-size specifies the maximum data unit size to be transferred for the service.
  • the fields delay and; jitter specify some basic QoS attributes for the service.
  • the priority attribute indicates the data / traffic handling priority for this service. Also,
  • the service—direction attribute indicates whether the service is one-way or two-way.
  • the attribute of QoS_type indicates a scheme of QoS used for providing services such as InterServ service provided with, for example, Di Serv or RSVP.
  • start_time and end_time indicate the start time and end time of the service.
  • the service provider network server (104) can use this information to schedule resources for the service.
  • the service-specific It will be apparent to one skilled in the art that other attributes may be included.
  • the Service-Spec field (705) there is a Tunnel-Spec field (706). This field contains tunnel information, similar to the Tunnel-Request field (308) of the MT-Request-A message (202A), but with some extra information added. For example, for a network 'tunnel' entry, a WLAN endpoint is provided, and for a terminal tunnel, a security key can be added for data encryption.
  • the final field of the Service-Request message (203) is Security_Field (707). This field is used to protect the entire message using a security association between the home 'network' authorizer (103) and the service provider 'network' server (104). Is done. Note that the exact algorithm used here depends on the actual embodiment.
  • the service 'provider' network server (104) may negotiate in any appropriate order for signaling optimization.
  • the service address management (204) procedure After receiving the Service_Request message (203), perform the service address management (204) procedure. In this procedure, the service identifier, the network interface server (104), and the session identifier contained in the Session ID (703) are searched to search the database. If there is a session identifier for the same mobile terminal (101), the service provider 'network server (104) Copy all information in the record, including the MT address, service details, etc., and reply directly to the Home's Network Authorizer (103) as a reply message.
  • the service provider 'network' server (104) creates a new entry using the new session identifier as its database index. .
  • the service 'provider' 'network' server (104) checks the Service—Spec field (705) from the home network authorizer (103) and if the requested service is not supported On failure, a message indicating failure is sent to the home 'network' authorizer (103). It is also possible to use some error code to identify the cause of the failure. Also, if certain attributes in the Service-Spec field (705) exceed the current capabilities of the service provider network (1003), the service provider's network server (1 04) is a new set of attributes that can attempt to interact with the Home 'Network Authorizer (103). This is the same Service—Request message (203) with the Service—Spec field (750) modified to the value proposed by the service provider network server (104). S, achieved by being sent back to the home 'network' authorizer (103).
  • the service 'provider''network' server (104) Tunnel—Check the Sepc field (706) to find the matching tunnel type. There may be multiple matches, but the service provider's network.server (104) should choose the first match.
  • the service 'provider''network' server (104) needs to provide information on the tunnel endpoint in the reply message.
  • the service provider network server (104) provides information specific to the type of tunnel and includes this information in the reply information.
  • the service 'provider''network' server (104) needs to assign a home 'agent to the mobile terminal (101). It is also possible to include certain security information in the reply message. Note that direction information (for example, one-way or two-way) may be added to the tunnel information field.
  • the structure similar to the Service-Request message (203) shown in Fig. 7 can be used for the Service-Reply message (205).
  • the content of (704) contains the address assigned to the mobile terminal (101), which is the list of entries of the address with the first octet indicating the length of the field in bytes. Can be.
  • the next part of the field is a list of addresses, with one octet indicating the type of address with the actual address. Wildcard addresses are also allowed. For example, if the Address' field is filled with all zeros, the local mechanism of the WLAN (eg, IPV6 automatic allocation (Non-Patent Document 17) or DHC Using P, it indicates that the mobile terminal (101) forms an address.
  • the Service-Spec field (705) in the Service-Reply message (205) contains the attributes agreed by the service 'provider' network'server (104). . If all attributes are approved by the service provider's network server (104), it is identical to the Service-Spec field (705) in the corresponding Service-Request message (203). is there. On the other hand, if they are not the same, the service provider network server (104) is making conflicting proposals to the home network authorizer (103).
  • the Tunnel Spec field (706) in the Service-Reply message (205) contains the tunnel configuration selected by the service provider 'network' server (104). The exact content of this field depends on the type of tunnel, and if a client-based tunnel type is selected, only one setting is required. For example, if Mopile IP v6 is agreed on, this field will contain the address of the home agent assigned to the mobile terminal (101) and the security information for binding update authentication. Utility keys, etc. will be included. The address in the Address-Request field (704) is used as the home address of the mobile terminal (101). Also, if a network-based tunnel type is selected, this field contains, for example, the endpoint address, the tunnel identifier, and all the detailed information needed for each of the supported tunnel types. Will be included.
  • the Home 'network authorizer (103) sends a WLAN_Request message (206) to the WLAN server (102).
  • This message is used to negotiate the necessary settings for service provision within the WLAN.
  • FIG. 8 shows an example of this message.
  • the WLAN_Request message (206) is composed of two fields, Home-Network-ID field (800) and MT-ID field (800), like Service-Request message (203). Contains.
  • the Network ID field (8001) contains the Caroline's home 'network identifier, and if a network policy applies to service provision, the WLAN server (1 0 1). 0 2) is passed.
  • the MT_ID field (802) is used to track the location of the mobile terminal (101). For example, it is possible to use the identifier of the access point associated with the identifier (eg, MAC address) of the lower layer of the mobile terminal (101).
  • the Address-Alloc field (803) contains a flag indicating whether the mobile terminal (101) needs to be assigned a local address of the WLAN and the type of address to be used.
  • the home 'network' authorizer (103) determines whether a local 'address is needed based on the selected tunneling scheme. In fact, for example, using the following definition, the first octet of this field indicates whether address allocation is required.
  • Dual— Stack— IPv4— Preferred :: 0x04;
  • the Service—Support field (804) is a compound field that contains all the attributes needed to support service provision within the WLAN.
  • the actual content is service specific and an example of the content of this field is as described in Data Structure 1.
  • Tunnel_Setup field (805) is a composite field, and uses the same format as the Tunnel and Spec feed / read (706) in the Service-Request message (203). .
  • the final field of the WLANJRequest message (206) is Security-Field (806). This field uses a security association to completely protect the entire message. The algorithm used for calculating this field depends on the actual implementation.
  • the WLAN server (102) After receiving the WLAN_Request message (206), the WLAN server (102) performs WLAN service end address management (207). For example, the local IPV 6 address assignment is If requested by the network authorizer (103), the WLAN server (102) finds the appropriate network section and assigns the terminal an IPV6 address. If necessary, the WLAN server (102) also updates the gateway (ie, assigns a new address to WLAN's firewall). As a result, the mobile terminal (101) can access the service using the assigned local address.
  • the local IPV 6 address assignment is If requested by the network authorizer (103), the WLAN server (102) finds the appropriate network section and assigns the terminal an IPV6 address. If necessary, the WLAN server (102) also updates the gateway (ie, assigns a new address to WLAN's firewall). As a result, the mobile terminal (101) can access the service using the assigned local address.
  • the WLAN server (102) also uses the information in the Service-Support field (804) to perform local authorization control. As with the service 'provider' network 'server (104), if any of the attributes exceed the current capacity of the WLAN, the WLAN server (102) will create a home' network 'authorization. Attempts to negotiate a new set of service details with the (103), for example, reducing the bit rate or changing the service time interval.
  • the WLAN server (102) does not need to do any special configuration.
  • the WLAN sensor (102) uses the information from the MT-ID field (802) to identify the endpoint of the tunnel. There is a need to.
  • the WLAN server (102) replies to the WLAN_Request message (206) using the WLAN-Reply message (208).
  • the WLAN_Reply message (208) is shown in Figure 8
  • Home—Network—ID field (80 1) and MT ID field (802 ) Is copied directly from the corresponding WLAN_Request message (206). These fields are used by the Home 'Network' Authorizer (103) to match request and reply message pairs.
  • the Address—Alloc field (803) in the WLAN—Reply message (208) contains information on the local end address of the WLAN assigned to the mobile terminal (101).
  • the first octet of this field indicates the type of address, as defined in the Address—Request field (307) in the MT 1-31-81_ message (202A).
  • the next part of this field contains the actual address assigned to the mobile terminal (101); for example, if an IPv6 address is assigned, the first octet is 0x02 and the next 32 octets contain the actual IPV6 address.
  • the Service—Support field (804) in the WLAN_Reply message (208) contains information on the service attributes defined in the WLAN—Request message (206). If the WLAN accepts these service attributes, the WLAN server (102) copies them directly from the WLAN_Request message (206). On the other hand, if the WLAN server (102) cannot accept the attribute, the WLAN server (102) adds the attribute with the new value set in the Reply message (208) and sends a new proposal.
  • the Tunnel_Setup field (805) in the WLAN-Reply message (208) is information on the tunnel to the mobile terminal (101). It shows the type of tunnel used in the first octet, and data specific to the type of tunnel in the second octet. For example, if Mopil IPV 6 is used for data traffic Has only the type of tunnel in this field,
  • the home 'network authorizer (103) sends the WLAN server (102) and the service provider' Network 'integrates information from the server (104). If the Service_Spec field (705) or the Service—Support field (706) is
  • the home network 'authorizer (103) checks the new values proposed by the service' provider 'network server (104) or the WLAN server (102), and If it is possible to accept these new values, the new configuration is acknowledged using the SPN-Config message (211) and the WLAN-Config message (211).
  • Service—Request message (203), Service—Reply message (205) and WLAN—Request message (206), WLAN—Reply message (208) Has no significant correlation. That is, they are performed one at a time, depending on the power performed in parallel, the implementation of the Home 'Network-Authorizer (103). For example, if the connection to the WLAN server (102) is idle, the home 'network' authorizer (103) will send a Service Request message. It is possible to make a decision to send the message (203) instead of ⁇ ] ⁇ : ⁇ -1 ⁇ (111 ⁇ 281: message (206)).
  • the SPN_Config message (from the home network authorizer (103)) to the service provider (network server) (104) can be used to confirm the new service parameters. 2 1 0) is sent.
  • the SPN-Config message (210) uses the same message format as the Service-Request message (203). Also, if the same message format is not used, some fields such as Address_Request may be omitted.
  • tunneling information may be added. For example, if a client-based tunnel (eg, Mopile IP) is used, the care-of address of the mobile terminal (101) assigned by the WLAN server (102) is inserted into the TunnelJRequest field (308). Is done. When a network-based tunnel is used, the end point address and port number of the tunnel of the WLAN are transmitted in this message. ⁇
  • a client-based tunnel eg, Mopile IP
  • the WLAN_Config message (2 1 1) is used for the same purpose, and the home.network.authorizer (103) uses this message when necessary to use the WLAN server (1021). ) To check the new settings.
  • This information can also be used to transfer tunnel information. For example, if a network-based tunnel is used, the tunnel endpoint address and port number of the service provider's network (1003) will be forwarded in this message to the WAN server (102). After that, the WLAN server (102) sends a response to the correspondent node. Order to set up the tunnel. On the other hand, if a client-based tunnel is used, the address of the terminal will be included in this message, so that the WLAN will fire for data 'traffic.
  • the home-networking equalizer (103) detects that the mobile terminal (101) is no longer present in the WLAN, it will set the Service—all set to zero. Can issue a WLAN—Config message (2 1 1) that includes a Support field (804). After receiving this type of message, the WLAN server (102) releases all resources allocated to the mobile terminal (101) and performs other appropriate actions.
  • the Home 'network authorizer (103) sends an MT-113 ⁇ 41_; 8 message (212B) in response to the MT-Request-1B message (202B). This message is forwarded by the access point (105) or other associated device to the mobile terminal (101) as the message MT-Reply_A message (212A). Note that the] ⁇ ⁇ 1_61_message (212A) and the MT-Reply-B message (2112B) have the same content and format.
  • the home network element between the network authorizer (103) and the mobile terminal (101) does not access the contents of these messages, and the access point (105) does not. , Simply recap the entire message Cellify and transfer it.
  • MT—Reply__A message (2 1 2 A) or MT—Reply B message (2 1 2 B) is shared between the mobile terminal (101) and the home network authorizer (103). Encrypted by the associated security association.
  • the MT-Reply-A message (21 2 A) is a response to the corresponding MT-Request-A message (202 A), and the access point (105) is ) Can be grasped.
  • the WLAN_Config message (211) can be carried on the message. is there.
  • the WLAN server (102) is an AAA server that forwards the MT-Reply_B message (212B) to the mobile terminal (101) using the parameters in the WLAN
  • the MT- The Reply_B message (2 1 2B) can be encapsulated in the Diameter EAP—Answer AVP.
  • the WLAN-Config message (211) may be encapsulated in another AVP of the same message. It is obvious to those skilled in the art that a similar scheme can be used even when another transfer protocol is used.
  • the MT—Reply_A message (2 1 2A) has the same structure as the _16 (11168 and message (202 A)) shown in Fig. 3.
  • the Message—Type field (301) has the MT— Request-A message (
  • the Message—Length field (302) is the Message—Type field (
  • MT-Reply_A message (2 1 2 A) in the Service-Request field (305), based on the user's subscription information, is set by the home 'network.
  • the Session_ID field (306) in the MT-Reply-A message (212 A) is copied directly from the MT-Request-A message (202A), but the mobile terminal (101) If not required by, it is actually possible to omit it.
  • the Address-Request field (307) in the MT_Reply_A message (212A) contains the address assigned to the mobile terminal (101). This should be used by the service 'application as a source' address.
  • the first octet of this field is the address type, followed by the actual address. For example, if the IPv6 address prefix is assigned, the first octet will be 0x03.
  • the next 32 octets also contain the prefix information used by the mobile terminal (101) to form the actual IPv6 address, for example, WLAN gateway address, DNS server address. It is also possible to include other address information. These attributes follow the address information above. Also, all 0 The value of the wildcard indicates that the mobile terminal (101) power s, the low-power stateless mechanism should be used to obtain the actual address information. .
  • the Tunnel—Request field (308) in the ⁇ _16_ message (2 1 2A) contains the settings for tunneling to access the service required by the mobile terminal (101). This depends on the type of tunnel, the first octet of this field indicates the type of tunnel used.
  • Mopile IPv6 is used for the client-based tunnel type, its value will be 0x06, as defined in the MTJRequest-A message (202A). Following the type attributes are the care-of address and the home agent address assigned by the WLAN, and, if necessary, the security key. The address in the Address_Request field (307) will be the home address assigned to the terminal.
  • the type attribute would be followed by the local endpoint address of the tunnel and the mobile terminal (101) to communicate securely with the endpoint. Security key and exists.
  • the WLAN—ID field (309) in the MT—Reply—A message (2 1 2A) is copied directly from the MT—Request—A message (202A). In order to optimize the signaling, it is actually possible to omit it.
  • the Security—Field (310) of the MT—Reply—A message (2 1 2A) is used to completely protect the entire message, and the mobile terminal (101) and the home network. Between the Authorizer (1 03) The utility association is used. Here, the same algorithm as that of the MT_Request-A message (202 A) should be used.
  • the mobile terminal (101) retrieves all necessary information, configures accordingly, and uses this setting to It is possible to start the service session (2 1 3).
  • the mobile terminal (101) can simultaneously request repetitive services, for example, a Voice-over-IP session along with a video streaming session. That is, it is possible to associate different service providers networks within the signaling.
  • requests for several services are grouped in the same message, the same mechanism and message structure as described above can be used.
  • the MT_Request-A message (202A), Service-Request field (305), Session-ID field (306), Address-Request field (307), Tunnel — It is possible to have multiple sets of Request fields (308). These four fields are grouped, and each service requested by the mobile terminal (101) contains one gnolap of these four fields.
  • the Home network authorizer (103) When requesting a Voice-over-IP session and a video streaming session, there are two groups of four fields listed. After receiving the MTJRequest—B message (202B) containing the same content as the message (202A), the home network authorizer (103) is requested by the mobile terminal (101). These four fields correspond to one specific service Retrieve information from each set of.
  • the Home 'Network Authorizer (103) performs signaling for each of the requested services as described above for a single service request. For example, the Home Network Authorizer (103) provides both an IMS subsystem and a network that provides streaming services.
  • WLAN_Request messages (206) for different services are sent to the same WLAN.
  • the Home 'Network' Authorizer (103) can gather information and send only one message. If multiple 1 ⁇ -1 ⁇ 911681: messages (206) need to be sent to the same WLAN, only one of them needs to make a request for local address allocation .
  • Home 'Network-Solizer-(103) integrates all service information into one MT_Reply_B message (2 1 2B) according to the requested service order, and establishes access' point (105). Via the mobile terminal (101). After that, the mobile terminal (101) can perform its own address configuration using the information in the integrated MT-Reply_A message (212A).
  • the service-session identifier as used in the Session_ID field (306) is used by the middle tier processor to multiplex the address and tunnel configuration.
  • the middle tier processor in the mobile terminal (101) maintains a local database of address and tunnel information for different service sessions. If the service 'session was created on a mobile terminal (101), the middle tier processor creates an identifier for it. This is the session identifier used in the Session-ID field (306) of the MT-Request-A message (202A). Include all address and tunnel information!
  • the middle tier processor After receiving the message (21 2 A), the middle tier processor creates a new entry in the database that contains all the information indexed by the session identifier.
  • the service 'application needs to start a new connection session, it sends a request with a session identifier to the middle tier processor, which uses the session identifier to Search the corresponding address and tunnel information.
  • the address and tunnel information is used by the normal stack, for example, at the IP layer, and appropriate bindings, such as sockets, are made to make the connection.
  • a controller-less WLAN such as a WLAN server (102) can actually exist.
  • the mobile terminal (101) must use the local mechanism of the WLAN to allocate addresses and set up tunnels.
  • the home network authorizer (103) sets all the Address_Request fields (307) and Tunnel-Request fields (308) in the MT-Reply-A message (212A) to 0, This forces the mobile terminal (101) to perform address configuration using a WLAN mechanism such as DHCP V6 or MIPV6.
  • the mobile terminal (101) may wish to cancel service registration in the WLAN. It is obvious to those skilled in the art that the above mechanism can be used even when deregistering a service.
  • the mobile terminal (101) can send an MTJRequest-A message (202A) set in the special value Service-Request field (305) indicating the end of the service.
  • Service-Request field 305
  • Service-Request field 305
  • service-Request field 305
  • the Session_ID field (306) of the MT_Request-A message (202A) can be set to the session identifier of the service to be terminated, and the MT_Request-A message (202A) of this type can be set. ), It is possible to omit the Address-Request field (307) and the Tunnel-Request field (308).
  • the Home Network Authorizer (103) processes the MTJRequest-A message (202A) as usual, and
  • the service session identifier is extracted from the Session—ID field (306). Then, the home network authorizer (103) searches its database to find the session entry created when the service was registered. This session 'entry stores information about the configuration of the service, for example, the assigned address and the tunnel configuration. Using this information, as usual, the home 'network' authorizer (103) will use the service 'provider' 'Send a Service Request message (203) to the network server (104) and send a WLAN_Request message (206) to the WLAN server (102). In these messages, the Service—Spec field (705) and the Service—Support field (804) are all set to zero.
  • the service 'provider' 'network' server (104) and the WLAN server (102) process the message as usual and the Service-Spec field (705) and the Service-Support field (804) are Read that all are set to 0, and understand that this is a service termination request.
  • These two servers search their database for service 'session' entries created during service registration, and respond to service sessions such as IP addresses and reserved bandwidth. Release resources.
  • MT Reply ⁇ ⁇ ⁇ ⁇ ⁇ A message Returned to mobile terminal (101). This message indicates that the service has been terminated and the reserved resources have been released.
  • the Service—Request field (305) contains information about the result. For example, in this field you could use the following line: ": removed. Request. IMS. Foo.bar.operator-name. Operator-group. Gprs".
  • the “removed” keyword before the “request” keyword indicates a successful unregistration of the service.
  • the GGSN has to reserve only 149 Kbps of bandwidth for the terminal's service. Just fine. Also, if the mobile terminal (101) uses the WLAN service again to register a service 'session, the policy' server should modify the GGSN setting to 1Mbps. It should be apparent to those skilled in the art that other types of setting / control / nodes are included in the policy / control.
  • This kind of policy 'control' should be done according to the user's subscription information and should therefore be done within the home 'network' domain.
  • the present invention uses a home network authorizer (103) to handle service requests and addresses (tunnel settings). Therefore, it has all the information it needs to make policy 'control decisions and sends it to the home' network domain's policy server from the home's network authorizer (103). It is possible to pass.
  • the policy server is then connected to a node such as a GGSN. It is possible to use the policy 'control' interface, which allows the user to operate as appropriate.
  • the policy server can notify other networks involved in providing services using the policy 'control framework', for example, the home 'network'domain's policy ' It is possible to notify the policy server within the new access rate limit, so that the WLAN policy server can adjust the local authorization management mechanism accordingly.
  • FIG. 9 shows an embodiment of a message used between the home network authorizer (103) and the policy server. This message begins with the Operation field (910). This field indicates the action taken by the policy server, and the possible values are:
  • the Home Network Authorizer (103) receives a request for a new service 'session from the mobile terminal (101), it uses the value of "Install” in the Operation field (910). Also, when the mobile terminal (101) terminates the service session, the home network authorizer (103) uses the value of ": Removed” in the Operation field (910). I do. If the service request from the mobile terminal (101) refers to an active service session, the value of "Update” is used. It should be apparent to those skilled in the art that other types of values can be used in an actual implementation.
  • the second field is the MT ID field (902). This field contains the identifier of the mobile terminal (101), for example, the IMSI of the Mopile user can be used.
  • the third field is the MT_Location field (903). This field is used by the policy server to search for location-based service policies, for example, if the terminal is on a given WLAN, providing twice the access rate. It is something. This field contains, for example, the WLAN identifier from the WLAN_ID field (309) of the MT_Request_A message (202A).
  • the next field is the MT_Service field (904). This field indicates what kind of service is being accessed by the mobile terminal (101). In addition, this field can include service 'session information. An example of the contents of this field could be the APN plus the session identifier.
  • the next field is the Tunnel-Setting field (905).
  • This field indicates the setup of the tunnel used by the mobile terminal (101) in the WLAN.
  • the content of this field is the type of tunnel, followed by the tunnel endpoint address, port number, and so on. Note that the exact format depends on the type of tunnel. Also, the type of tunnel used is defined in the Tunnel-Request field (308) of the MT_Request_A message (202A).
  • the last field of the message is the MT_Address field (906).
  • This field contains the address used by the mobile terminal (101) in the WLAN. This is the policy Used by the server to set filtering rules to access the service.
  • the present invention provides a management method for managing address assignment of a terminal in a WLAN interconnection.
  • an address is allocated to a mobile terminal based on the service requested by the mobile terminal and its subscription information, and address management is performed without requiring access to local resources. It becomes possible.
  • the present invention provides a method for controlling the configuration of a tunnel in a WLAN interconnect.
  • the mobile terminal can support network and client-based tunnel setup simultaneously with service authorization.
  • the present invention provides a method of interconnection in a policy-control framework. By using the provided interface, it is possible to propagate service permission, address assignment, and tunnel setting information to the policy server, and to take appropriate action to deliver the service to the terminal. It will be possible to do so. In all methods, it is possible to achieve address management, tunnel configuration and service authorization with a single round-trip message exchange between the terminal and its home domain server. This saves valuable signaling time and bandwidth.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Description

明 細 書
WLAN相互接続におけるサービス及びア ドレス管理システム及び方法 技術分野
本発明は、 無線データ通信の分野に関する。 また特に、 本発明は、 無 線 LAN (WLAN) 環境において、 他のネットワークから訪れるモバ ィル .ユーザのためのア ドレス管理に関し、 WLANが、 例えば、 別の 管理ドメイン内に存在し、 他の無線技術を使用する 3 Gネットワークや W L A Nなどの公衆無線ネットワークとの相互接続 （inter-networking ) を行う際に使用可能なものである。 また、 本発明は、 ア ドレス割り付 け、 構成、 トンネリ ングの設定などのために、 WLAN及び相互接続ネ ットワーク （inter-worked network) に加えて、 移動端末によって利用 可能であり、 その結果、 移動端末は WLANにおいて加入したサービス
背景技術 '
WLAN相互接続 （WLAN interworking) では、 端末が加入したす ベてのサービスにアクセスすることができるように、 端末はァドレス付 けが可能 （addressable) でな必要がある。 サービスが I Pを通じて伝 送される場合、 端末は、 ある I Pァドレスに関連付けられているはずで ある。 モパイルの世界では、 端末の接続点が頻繁に変わり、 端末がある アクティブなサービス ' セッションの間に、 いぐつかの ドメインを渡り 歩くことが十分に起こり得る。この端末の移動性の要件を満たすために、 ア ドレス管理のメカニズムには、 端末が接続点を変更するごとに、 端末 のアドレスを構成 （configure) し更新することが要求される。 モパイル I Pは、 インターネッ ト技術検討委員会 （ I ETF) で公開 されている標準化技術であり （非特許文献 1) (非特許文献 2) 、 移動 端末のためのァドレス管理と トラフィックのルーティングに対する解決 策を提供する。 この技術によって、 様々な I Pネットワーク内を動き回 る場合に、 ユーザは、 同一のア ドレスを使用しながら位置特定可能な状 態 （reachable) となる。 移動性が I Pレベルで管理されているので、 モ パイル I Pは、 基礎となるリンク層の技術に束縛されず、 3 Gのセルラ 'ネットワーク、 又は無線 LAN (例えば、 8 0 2. 1 1のネットヮー ク） 内の端末に対して、 同一のプロ トコル ·スタックの適用が可能とな る。 例えば、 WL ANと 3 Gのセルラ 'ネッ トワークとの相互接続など のアクセス技術の融合において、 この種の調和したレベルの解決策が、 特に有用である。 モパイル I Pでは、 I P接続によってア ドレス管理が 行われ、 I P接続が利用可能でない場合には、 ア ドレス管理が不可能と なる。 また、 さらに、 モパイル I Pでは、 端末が、 ホーム ' ア ドレスを 有し、 かつ、 そのホーム 'エージェントを知っている必要がある。 こう した要件は、 例えば、 端末が最初にフォーリン WL ANで動作を開始す る場合など、 相互接続の動作過程では満たされないかもしれない。
また、 モパイル I P V 6のドラフトでは、 移動ノード （mobile node ) のホーム 'ア ドレスのセッティング方法が導入されている （非特許文 献 2) 。 端末は、 例えば、 DHC P V 6 (非特許文献 3 ) を使って、 ま ず、 気付アドレス （Care of address) を最初に生成し、 このアドレスを 使用して、 最終的なホーム ·ァドレスを設定するホーム 'ネットワーク との通信を行う。 しかし、 WL ANから得られた気付ア ドレスを使用し た場合には、 移動ノードのホーム 'ネットワークは必ずしも位置特定可 能な状態とはならないので、 WL AN相互接続においては、 動作が不可 能となる。 さらに、 複数回のやり取りを行うコンフィギュレーション処 理は、 時間を消費するものであり、 ユーザの期待に沿うものとはならな い。
また、 ダイァメータ 'モパイル I P V 6の適用 （非特許文献 4) によ つて、 AAAの構成に基づいて、 モパイル I P V 6のア ドレス管理のた めの解決策が示されている。 この解決策では、 AAAサーバと移動先及 ぴホーム 'ネッ トワークのクライアントが、 ァドレス更新及びエージェ ント発見を実行することが利用されている。 そのメカニズムでは、 移動 ノードは、 例えば、 ルータ ·ァドバタイズメント 'メッセージを聞くこと ができるなど、 メッセージ交換用のローカル I P接続を有することが要 求されるが、 フォーリ ン ' ドメインのローカル ' ポリシーによって、 必 ずしも可能であるとは限らない。 さらに、 この機構は、 ア ドレスが移動 端末のホーム · ドメインに属する状況でのみ提供されるものである。 W LAN相互接続では、 端末がアクセスしているサービスに依存する別の ドメィンからのァドレスを端末が使用することになり、 このァドレスは 端末のサービス ' リ クエス トの情報を持たないので、 この機構は WLA N相互接続をサポートすることはできない。 この機構は、 モパイル I P V 6環境のために設計されており、 したがって、 モパイル I Pスタック のない端末では動作不可能である。
さらに、 3 GP Pによって解決策、 端末のア ドレシングと トンネリ ン グとを管理するための GTP (非特許文献 5) が提供されている。 GT Pは、 コントロール用の GT P— C、 及び、 ユーザ 'データのトラフィ ック用の GTP—Uの 2つのパートを有している。 GTPは、 UDP上 で動作し、 UD Pパケッ ト中のユーザ 'データをカプセル化する。 この GTPは、 GPR S (非特許文献 6)ネッ トワーク用に設計されており、 例えば、 GGSN、 S GSNノードなどの GPR Sネッ トワークの特徴 に非常に依存しており、 単純な無線アクセス 'ネッ トワーク （例えば、
Figure imgf000006_0001
∞¾///: 9soddsdd.r d:--
()Ιg ΘΘ
//////£^g:sau9sdsd:9s SSdd dJ*..t
SOJr 非特許文献 1 2 「The Network Access Identifiei'」 htt V/www. ietf.org/rfc/rfc2486.txt
非特許文献 1 3 「Numbering, addressing and identification
(Release 5)」 3GPP TS 23.003 V5.3.0 (2002.06)
ftp://ftp.3gpp.org/Sepcs/archive/23_series/
非特許文献 1 4 「Port'Based Network Access Control」 IEEE Std 802.1X-2001 http://standards.ieee.org/getieee802/
非特許文献 1 5 「Diameter Extensible Authentication Protocol (EAP) ApplicationJ
http：〃 www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt 非特許文献 1 6 「Diameter NAS EQ ApplicationJ
http7/www.ietf.org/internet-drafts/draft"ieti-aaa_diameter-nasreq-09 .txt
非特許文献 1 7 「IPv6 Stateless Address AutoconfigurationJ http ://www. ietf.org/rfc/rfc2462. txt
通常、 W L A N及び相互接続ネッ トワークは、 異なる管理ドメインに 存在している。 これは、 ア ドレス空間が別々に管理されていることを意 味している。 したがって、 移動端末が、 そのホーム 'ネットワークとは 異なるドメインの W L A Nに移動した場合、 端末への連続的なサービス 配送を保証するために、 何らかのア ドレス構成を実行しなければならな い。 このア ドレス構成には、 例えば、 I Pア ドレス割り付け、 ア ドレス 登録、 トンネリングの設定なども含まれている。
W L A Nを通じて端末に任意のサービスが配送されるようにするため には、 ア ドレスの限定が行われる。 例えば、 W L A Nから 3 Gネットヮ ーク内の I M S (非特許文献 7 ) サービスにアクセスするためには、 端 末は、 I M Sを提供するネットワークに属するァドレスを有する必要が あり、結果的に、異なるサービスへの並列のアクセスを行う移動端末は、 複数の I Pァドレスが割り当てられるよう要求される。
W L A Nでは、認証及びその許可が与えられる前に、端末が、例えば、 通常のデータ ·パケッ トを送受信するなど、 いかなるリ ソースを使用す ることも許されていなレ、。例えば M I P V 6の中で示唆されるような通 常の機構では、 許可処理の成功後にのみァドレスの構成が行われるが、 この種のアプローチは時間がかかり、 いくつかのサービスにおける要件 を満たすことができない。 この許可処理の前にァドレス構成を行うため には、 ァ ドレス構成に関連した情報がアクセス · コントロール · メ ッセ ージに統合される必要がある。 また、 ア ドレス管理は通常、 ユーザの加 入情報に基づいており、 移動端末のホーム ·ネッ トワークによって管理 される必要がある。 しかし、 任意の外部サービスにおいては、 ホーム ' ネットワーク以外のドメィンから、 ァドレスが割り当てられる必要があ る。 この場合、 ホーム 'ネッ トワークが、 ア ドレス割り当てやそのドメ インが有する他の情報に関するやり取りを行えるメカニズムが必要とな る。
また、 端末がア ドレスを変更する場合、 その端末に関連した終端点間 (ェンド . トウー .エンド） Q o Sが影響を受けることになる。例えば、 もしァドレスが変わった場合には、 送信元ァドレス又は送信先ァドレス の情報に基づく トラフィック · フィルタは、 流れ （フロー） を正確に分 類することは不可能となる。 ファイア ' ウォールや他のトラフィック · コントロール機能を実施する W L A Nについては、 さらに、 端末の新し いア ドレスが示される必要があり、 さもないと、 トラフィックが妨げら れるカ 又は、 中断されることとなる。 発明の開示 端末が W L A Nに入った場合、 端末は、 リ ソースへのアクセスを行う ために、認証処理及び許可処理を完結しなければならない。本発明では、 アクセス · コント口.ール · メカニズムに統合されるァ ドレス管理への解 決策が示される。 この統合によって、 アクセスの許可と同時に、 端末の ア ドレスの割り当てが行われることが可能となる。 また、 端末は、 ァク セス . コントロール · メカニズムを再利用して拡張するので、 新しいプ 口 トコルを実施する必要はない。 アドレスの構成処理は、 アクセス . コ ントロール処理の固有の暗号化及び保護によって守られ、 したがって、 特別なセキュリティの設定を必要としない。
また、 本発明は、 さらに、 端末のホーム ·ネッ トワークが端末のサー ビスを提供するネッ トワークとァ ドレス管理の取り決めを行うための手 段を提供する。 この種のやり取りは、バック 'エンド 'プロセスであり、 移動端末と W L A Nには明らかなもの （transparent) であり、 その取 り決めの結果は、 サービス許可処理を利用して、 W L A N及び移動端末 に送られることとなる。
また、並列のアクセス'セッションが同一の端末に存在する場合には、 複数のア ドレスが要求されることとなる。 本発明では、 きめ細かいサー ビス許可処理を使用して、 端末がセッションに関連するァドレスを取得 するための方法が提供される。 各セッショ ンは、 関連付けられたァドレ スを使用して、 新しいア ドレスへの移行が行われる。
また、 ア ドレス管理は、 ポリシー ' コントロール ' メカニズムにも統 合される。 ポリシー ' コントロールは、 ア ドレスが変わった後、 必要な 場合には、 端末及びそのホーム ·ネッ トワークに W L A Nを構成するた めの手段を提供する。 Q o S、 又は、 トンネリングの情報は、 既存のポ リ シ一 . コントロール処理で利用可能なチャンネルを使用した新しいス テータスに従って、 修正され、 供給される。 これによつて、 ローミング 時間内に、 ア ドレスのスムーズな移行を達成することが可能となり、 Q o Sの中断を最小限に抑えることが可能となる。 図面の簡単な説明
図 1は、 本発明の W L A N相互接続における移動端末のア ドレスの割 り当て、 トンネルの設定、 サービスの取り決めの管理に使用されるネッ トワーク構成の一例を示すプロック図、
図 2は、 図 1に示される構成で使用される、 端末のア ドレスの割り当 て、 トンネルの設定、 サービスの取り決めのためのメッセージ . シーケ ンスの一例を示すシーケンス 'チャート、
図 3は、 図 2に示されるメッセージ交換で移動端末によって使用され るメッセージの構成の一実施例を示すデータ構造図、
図 4は、 ァドレス割り当て要求のために移動端末によって利用される フォーマツ トの一例を示すデータ構造図、
図 5は、 W L A N相互接続における移動端末のア ドレス割り当て、 ト ンネルの設定、 サービスの取り決めのための図 1で示されるフレームヮ ークにおけるホーム ·ネッ トワーク ·ォーソライザの一実施例を示す状 態遷移図、
図 6は、 ホーム ·ネッ トワーク ·ォーソライザで要求メッセージの処 理手続きを行うために使用され得るフローチヤ一トの一例を示すフロー チャート、
図 7は、 サービス ·プロバイダ 'ネッ トワーク .サーバと移動端末の サービスの詳細、 ア ドレス割り当て、 トンネル設定の取り決めを行うた めに、 ホーム 'ネッ トワーク ' ォーソライザによって使用されるメッセ ージの構造の一実施例を示すデータ構造図、
図 8は、 W L A Nサーバと移動端末のサービスの詳細、 ア ドレス割り 当て、 トンネル設定の取り決めを行うために、 ホーム 'ネッ トワーク . ォーソライザによって使用されるメッセージの構造の一実施例を示すデ ータ構造図、
図 9は、 ホーム 'ネットワーク · ドメィン内のポリシー ·サーバの移 動端末の状態に関する更新を行うために、 ホーム ·ネットワーク ·ォー ソライザによって使用されるメッセージの構造の一実施例を示すデータ 構造図である。 発明を実施するための最良の形態
本発明は、 W L A Nが他のネットワークと相互接続 （inter-work) す るために使用されるものである。相互接続されたネットワークとしては、 別の W L A N又は公衆セルラ 'ネットワークが可能であり、 どちらの場 合においても、 容易に、 本発明を適用することが可能である。 また、 本 発明は、 ァ ドレス管理や、 ァ ドレスの遷移 （つまり、 モビリティ · コン トロール） に関連したサービス提供を行うことを目的として使用される ものである。
ここで提案される機構 （スキーム） を適用する場合には、 特別なイン ターフェースやプロ トコルを実施する必要はない。 この機構は、 既存の アクセス ' コントロール ' メカニズムを再利用し、 必要な機能性を支援 するために、 その属性のうちのいくつかを拡張する。 ア ドレス割り付け では、 その修正がサービス許可手続きに統合される。 許可手続きが、 認 証から得られた信頼によって暗号化され保護されるので、 ァドレス情報 も同一のセキュリティ · レベルで保護され、 許可情報の一部として示さ れて、 通常の許可情報と同一の方法で転送可能となる。 例えば、 A V P に特有の許可としてダイァメータ （非特許文献 8 ) に含まれたり、 E A P方法による許可が利用可能な場合には、 E A P (非特許文献 9 ) の属 性として含まれたりすることが可能である。
端末が W L A Nに入った場合には、 サービスを利用することが認めら れる前に、 認証及び許可が行われる。 許可手続きでは、 端末が、 ァクセ スしょうとするサービスを要求し、 この情報は W L A Nを通じて端末の ホーム 'ネットワークに渡される。 端末のホーム 'ネットワークは、 ュ 一ザの加入者プロフィールに基づいてサービスを許可すべきか否かを決 定する。 さらに、 要求されたサービスに応じて、 端末のホーム ·ネット ワークは、 サービスに使用されるア ドレスを決定する。 例えば、 I M S サービスについては、 ア ドレスは I M Sァドレス空間から割り当てられ る必要があり、 一方、 ローカル W L A Nサービスについては、. ローカル で取得されたア ドレスで十分である。 また、 さらに、 ア ドレス管理に関 連するトンネリ ングの情報の確認が行われる。
ァ ドレス情報は許可情報に含まれ、 許可成功メッセージと共に送られ る。 この情報の一部は、 W L A Nに送られ、 一部は、 通常の許可手続き と同様、 端末に送られる。 例えば、 端末が端末自体のア ドレス構成を行 えるようにするために、 ア ドレスが端末に送られる必要がある。 また、 もしネットワーク ·トンネリングが必要な場合には、 W L A Nによって、 トンネリングの情報が使用される。
また、 ア ドレスの変更が必要な場合には、 サービス許可の詳細な手続 きを行わずに、 迅速な更新を行うために、 再許可手続きを利用すること が可能である。
また、 端末がサービスへのアクセスを開始した場合に、 ポリシー - コ ントロールが開始される。 ア ドレス情報は、 端末のホーム 'ネットヮー クのポリシー ·サーバによって利用可能となり、 その後、 ポリシー .サ —バは、ポリシー決定をァドレス情報に基づいて行うことが可能となる。 また、 ァドレスの変更時には、 ポリシー ·サーバに対して、 対応するポ リシ一を更新するよう通知が行われ、 その結果、 Q o S及ぴサービス提 供が保証される。
発明の理解を支援するため、 次の定義が使用される。
「WL AN」 は、 無線のローカル 'エリア 'ネッ トワークを指すもの であり、 無線技術を通じて移動端末に LANサービスを提供するための 任意の数の装置を含むものである。
「3 Gネッ トワーク」 は第 3世代の公衆アクセス ·ネッ トワークを指 すものであり、 例えば、 3 GP P (非特許文献 1 0) や 3 GP P 2 (非 特許文献 1 1 ) によって定義されるシステムである。
「移動端末」 は、 無線技術によって WL AN及び他のネットワークに よって提供されるサービスへのァクセ 'スに使用される装置を指すもので ある
「ホーム .ネッ トワーク」 は、 移動端末 （MT) のサービス加入情報 が格納されているネッ トワークを指すものであり、 相互接続のシナリォ では、 MTが最初に加入したネッ トワーク、 又は、 MTの加入情報に完 全にアクセスすることが許可されている訪問先のネッ トワークである。
「サービス ' プロバイダ 'ネッ トワーク」 は、 MTが要求したサービ スが提供されるネッ トワークを指すものであり、 例えば、 ホーム ·ネッ トワーク、 WLAN、 外部ネッ トワークなど、 任意のネッ トワークが可 能である。
「ネッ トワーク 'エレメント」 は、 情報処理を実行することが可能な ネッ トワーク内で機能している任意の装置を指すものである。
「ポリシー ·サーバ」 は、 ネッ トワーク · ドメィンのポリシー · コン トロール機能を実行するネットワーク ·エレメントを指すものである。 ポリシー ' コントロール機能は、 例えば、 ローカルのリ ソース配分、 パ ケッ ト ' フィルタの更新、 ルーティングの更新などを含んでいる。 「エア . インターフェース」 は、 移動端末が W L A Nにアクセスする ための任意の無線アクセス技術を指すものである。
「ス トリーム」 は、 ある属性を共通に持っているネッ トワーク内で転 送されるパケッ トの集まりである。
「トラフィック」 は、 ネッ トワーク内で転送されるス ト リームの集ま りである。
「フロー」 は、 データ ' パス、 及び、 ス トリームを伝送するために使 用されるデータ · パスに必要とされるネッ トワーク · リ ソースを指すも のである。
「Q o S」 は、 データ ' ス トリーム又はトラフィックのサービス品質
(Quality of Service) の用語を指すものである。
「メッセージ」 は、 相互接続をコントロールする目的で、 ネッ トヮー ク ·エレメント間で交換される情報を指すものである。
「オペレーション ·シーケンス」 は、相互接続コントローノレのために、 任意のネッ トワーク 'エレメント間での一連のメッセージ交換を指すも のである。
「上位レイヤ」 は、 現在のエンティティの上に存在し、 現在のェンテ ィティから渡されたバケツ トを処理するすべてのエンティティを指すも のである。
「クライアントに基づく トンネル」 は、 トンネルの終端点のうちの 1 つが移動端末である トンネリング機構を指すものである。
「ネッ トワークに基づく トンネル」 は、 トンネルの終端点が移動端末 以外のネッ トワーク 'エレメントに存在する トンネリング機構を指すも のである。
以下の記述では、 本発明を完全に理解するための説明において、 具体 的な数、 時間、 構造、 プロ トコルの名前、 その他のパラメータが使用さ れるが、 このような具体的な詳述がなくても、 本発明の実施が可能なこ とは当業者にとって明白である。 また、 よく知られた構成要素やモジュ ールに関しては、 本発明を不必要に不明瞭なものとしないようブロック 図で示されている。
端末が高度な移動性を有するという特性により、 モビリティ ' コント ロールは、 WL AN相互接続における最も顕著な問題のうちの 1つであ る。 端末が移動する場合、 端末は、 接続点に局所的 （ローカル） でない アドレスを使用するよう要請されている。 例えば、 WL ANに入り込ん だ 3 G端末に関しては、そのホーム'ネットワークのサービス（例えば、 I MSサービス） にアクセスするためには、 3 Gドメインのア ドレスが 必要とされる。 端末が、 3 Gネッ トワーク内にあるサービスを開始した 場合、 ア ドレスは、 例えば、 GPR Sサービス （非特許文献 6) などの 3 Gのスキームに従って割り当てられ、 このア ドレスは、 端末の 3 Gセ ルラ 'インターフェースに関連付けられる。 また、 端末が WLANドメ インに入る場合には、 高いスループットを実現することができるので、 その W LANィンターフェースを使用して通信することが望まれる。 例 えば、 2重のインターフェース （GPR S及ぴ I EEE 8 0 2. 1 1) を備えた PDAは、 道路上では G P R Sインターフェースを使用し、 ホ ッ ト ' スポット内では I EEE 8 0 2. 1 1ィンターフェースを使用す ることが望まれる。 端末が WL ANインターフェースを使用して 3 Gサ 一ビスにアクセスする場合には、 端末は、 3 Gインターフェースから得 られたものと同一のァドレスを使用し続ける必要がある。 そうでなけれ ば、 端末はサービス中断に直面し、 セッションを再度初期設定しなけれ ばならず、 これは、 ユーザにとって望ましいことではない。 また、 使用 中のア ドレスは WL ANに局所的ではないので、 トンネルは、 端末から サービス ·プロバイダ ·ネッ トワークまで設定されなくてはならない。 図 1には、 ァドレス割り付けと トンネルのセッ ト . アップのための本 発明の実施例が示されている。 なお、 混乱を避けるため、 シグナリング に参加するネッ トワーク 'エンティティのみが図示されている。
移動端末 （ 1 0 1) はネッ トワークからあるサービスを要求するェン ティティである。 実際には、 例えば、 Bluetoothリンクによってラップ トップ . コンピュータに接続されたハンドセッ トなどのように、 レヽくつ かのエンティティを有することが可能であるが、 単純化のため、 図 1に は 1つのセッ トとして描かれている。 WLAN機能 （WLAN function) ( 1 0 0 1) 内において、 アクセス · ポイント （ 1 0 5) は、 移動端末 (1 0 1) に対して WLANアクセスを提供するエンティティである。 移動端末 （1 0 1) が WLANサービスを利用する許可が与えられるま で、 アクセス ' ポイン ト （1 0 5) は、 移動端末 （ 1 0 1) からのデー タ- トラフィックをすベて遮断するが、 ある特定のデータ ·バケツ 卜のみ を許可するコントローノレ · チャンネノレが、 アクセス ' コントローノレ · シ グナリングを行うために開いた状態 （open) となる。 移動端末 （ 1 0 1 ) は、 無線リンク （1 0 1 1) を通じてアクセス ' ポイント （ 1 0 5) と通信を行う。 このリンクとして、 例えば、 I EEE 8 02. 1 1、 H i p e r LAN/ 2、 赤外線などを始め、 どのような種類の無線技術を 使用することも可能であり、 同様のアクセス · コントロール技術が適用 可能な場合には、 このリンクにおいて、 例えば光ファイバなどの他の技 術を使用することも可能である。 また、 WLAN管理サーバ （WLAN サーバ） （1 02) 力 WLAN内の別のエンティティとして存在して いる。 この WLANサーバ （ 1 0 2) は、 ア ドレス空間の管理及び WL ANのリソース管理を担当しており、 WLANのゲートウェイ上に存在 する力 、 単純な WLANではアクセス . ポイント （ 1 0 5) に共設され ている。 WLANサーバ （1 0 2) は、 インターフェース （1 0 1 5) を介して、 アクセス ' ポイント （105) と通信を行う。 これは、 例え ばエア .ィンターフェースを介する Q o Sの管理など、 WL ANリ ソー ス ' コントロールやサービス提供のためのものである。 また、 WLAN を管理するため、 このサーバは、 例えば、 不図示の WL ANゲートゥェ ィゃファイア . ウォールなど、 WL ANの他のエンティティとの相互動 作を行うことも可能である。
端末のホーム 'ネッ トワーク （ 1 002) では、 ホーム 'ネッ トヮー ク ·ォーソライザ （Home Network A thorizer) (1 03 ) がサービス 許可及ぴア ドレス割り付けの管理を行う。 アクセス ' ポイント （1 05 ) 及び WL ANサーバ （1 02) は両方とも、 リンク （1 0 1 2) 及び リンク （1 0 14) を介して、 サービス制御情報を取得するためにホー ム 'ネッ トワーク ' ォ一ソライザ （1 03) とそれぞれ通信を行う。 な お、 物理的に、 リ ンク （1 01 2) 及びリンク （1 014) を同一とす ることも可能であり、 すなわち、 同一のプロ トコルを使用し、 同一の端 末間で、 同一のパケッ トにカプセル化された場合でも、 それらは、 論理 上分離される。
移動端末 （101) は、 それが加入しているすべてのサービスを要求 することが可能である。 これらのサービスは、 ホーム 'ネッ トワーク （
1 002) 、 個別のサービス ·プロバイダ 'ネッ トワーク （ 1 003) 、 又は、 WL AN自体にあるかもしれない。 サービスが、 ホーム 'ネッ ト ワーク （1002) 又は WL ANによって提供される場合には、 サービ ス .プロバイダ .ネッ トワーク （ 1 003) は、 これらのネッ トワーク とオーバラップすることになり、 コント口ール機能を両方に関連付ける ことが可能となる。 また、 サービス ' プロバイダ 'ネッ トワーク管理サ ーバ （サービス ' プロバイダ 'ネッ トワーク ·サーバ） （1 04) は、 サービス許可及びサービス 'プロバイダ 'ネッ トワーク （ 1 003) の ア ドレス割り付けを管理する。 ホーム ' ネッ トワーク 'ォーソライザ （ 103) は、 コントロール 'インターフェース （1 0 1 3) を介して、 サービス ·プロバイダ'ネッ トワーク 'サーバ （1 04) と通信を行う。 実際には、 サービス ' プロバイダ ·ネットワーク （ 1 003) として、 WLAN、 ホーム 'ネッ トワーク （ 1 002) 又は別のネッ トワークを 利用することが可能である。 また、 サービスが、 ホーム 'ネッ トワーク ( 1 002) で提供される場合には、 このインターフェースは内部イン ターフェースとなり、 正確なフォーマッ トや、 後述の実施例に記述され るものと同一のプロ トコルを使用する必要はない。
図 2は、 上記のフレームワークを使用して、 WL AN相互接続のアド レス管理のためのオペレーシヨン'シーケンスの一例を示すものである。 なお、 この動作では、 移動端末 （MT) (1 0 1) がすでに、 WLAN の関連付け及び認証手続き （20 1) を終了していると仮定する。 すな わち、 移動端末 （1 0 1) とアクセス ' ポイント （1 05) は、 相互に 認証し合っており、以降のメッセージ交換のための暗号化による保護が、 すでに行われている。 移動端末 （1 0 1) は、 WLANを通じて任意の サービスにアクセスしたい場合には、 リ ンク （1 0 1 1) を介して、 ァ クセス 'ポイント （1 05) に MT_Request_Aメッセージ （ 202 A) を送信し、 そのメッセージは、 ホーム 'ネッ トワーク ·ォーソライザ （ 1 03) に届けられる。 このメッセージは、 認証手続き （20 1) から 生成されたキーによって、 終端点間 （エンド ' トゥー 'エンド） で保護 されている。 図 3は、 メッセージ MT_Request_Aメッセージ （202 A ) の実施例を示している。
メッセージは Message— Typeフィールド （30 1) から始まる。 この フィールドは、 例えば、 要求、 返答など、 どの種類のメッセージがカプ セル化されているかを識別する。 このフィールドの長さは 1ォクテツ ト であり、 メッセージ · タイプは整数番号によって表わされる。 これは、 エア ·ィンターフェースを通じたシグナリングに対して制限されたリソ ースを節約するものである。 なお、 必要な場合には、 このフィールドが 他のフォーマツ トも採用できることは当業者にとっては明白である。 Message— Typeフィールド （ 3 0 1 ) に続いて、 Message— Lengthフィ一 ノレド （3 02) が存在する。 これは、 Message_Typeフィールド （3 0 1) を含む全体のメッセージの長さに関する情報を含んでいる。 また、 次のフィールドは、 Domain_Nameフィールド （3 0 3) である。 この フィールドは、 移動端末 （ 1 0 1 ) のホーム ' ドメインを識別する。 な お、 ネッ トワーク · アクセス識別子 （Network Access Ident ier： N A I ) (非特許文献 1 2) を使用することも可能であり、 この場合には、 例えば 「UserID@home. domain.3gpp.org」 の开式となる。 ユーザの識 別情報を保護するため、 「@」記号の前の UserlD部分は、例えば「roamed 」 などのワイルドカード値を使用する。 ホーム ' ドメイン情報は、 移動 端末 （1 0 1) のホーム 'ネッ トワーク ·ォーソライザ （1 0 3) に対 して、 メッセージをルーティングするために使用される。
上記の 3つのフィールド、 Message一 Typeフィールド （3 0 1) 、 Message— Lengthフィ一ノレド （3 0 2) 及ぴ Domain— Nameフィ一ノレド ( 30 3) は、 移動端末 （1 0 1) とアクセス 'ポイント （ 1 0 5) と の間のセキュリティの関連付けによって保護される。 このセキュリティ の関連付けは、 エア 'インターフェースの保護のための認証手続き （2 0 1) から得られる。 したがって、 目的を達成するために、 アクセス . ポイント （1 0 5) 、 これらのフィールドに含まれている情報にァク セスすることが可能である。 Domain— Nameフィールド （ 3 0 3 ) に続 くフィールドは、 移動端末 （1 0 1 ) とホーム 'ネッ トワーク ·ォーソ ライザ（1 0 3)との間のセキュリティの関連付けによって保護される。 例えば、 これには、 ホーム 'ネッ トワーク 'ォーソライザ （1 03) の パブリ ック · キーが可能であり、 すなわち、 認証手続き （20 1 ) に由 来したセッション ' キーである、 また、 メッセージ保護のために使用さ れるキーのインデックスを示すために、 Domain— Nameフィールド （3 03) の UserlD部分を使用することも可能である。
Domain— Nameフィールド （ 303) の後には、 MT一 IDフィールド （ 304) が存在する。 このフィールドは、 ホーム 'ネッ トワーク （1 0 02) のコンテキス トにおいて、 移動端末 （1 01) を一意に識別する ための情報を含んでいる。 これは、 例えば、 移動端末 （10 1) の IM S I (非特許文献 1 3) 、 又は、 認証手続きで獲得された TMS I (非 特許文献 1 3) が可能である。 ホーム 'ネッ トワーク ·ォーソライザ （ 1 03)は、ユーザの加入情報を検索するため、 この識別子を利用する。 ホーム 'ネットワーク ·ォーソライザ （1 03) が実際のユーザ識別情 報にそれをマツビングすることができる限り、 このフィールドに他のフ ォーマッ トを使用することも可能であることは、 当業者にとっては明白 である。
次のフィールドは Service— Requestフィールド （ 305) である。 こ のフィールドは、 ホーム 'ネッ トワーク 'ォーソライザ （1 03) に対 してアクセスすることを望むサービスを示すため、 移動端末 （1 0 1) によって使用される。 メッセージは、 移動端末 （1 0 1) とそのホーム •ネッ トワーク ·ォーソライザ （1 03) との間の.ものなので、 これは、 特定のオペレータ及びネッ トワークに特有のものである。 例えば、 3 G P Pネットワークでは、 これは、 使用する GG S N及びアクセスする特 別のサービスを識別するための APN (非特許文献 1 3) であり得る。 ホーム 'ネッ トワーク （ 1 002) が別のタイプである場合には、 他の フォーマツ トを使用することが可能であることは、 当業者にとって明白 である。 さらに、 例えば、 帯域幅の要求など、 他のサービス · リクエス ト情報を追加することも可能である。 フィールドに利用可能な値として 、 「2M. bandwidth. request. IMS.ioo. bar. operator-name. operator-gr oup.gprs」 があり得る。 「requestj の後の部分は、 サービスを識別する 標準の A P Nであり、 また、 「request」 の前の部分は、 特定のサービス . リクエストである。 実際のリクエスト属性は、 サービスに依存してお り、 また、 オペレータが定義することも可能である。 移動端末 （1 0 1 ) は、 S I M又は U S I Mカードから、 フォーマットに関する情報を獲 得することが可能である。
また、 Session— IDフィールド （3 0 6 ) はセッション制御情報を提供 する。 これは、 移動端末 （1 0 1 ) 力 このサービスの要求がホーム . ネットワーク ·ォーソライザ ( 1 0 3 ) に関連するセッションであるこ とを識別するために使用される。 セッションの識別子は、 移動端末 （1 0 1 ) 内では局所的に一意であるべきであり、 移動端末 （1 0 1 ) は、 すべてのサービス ' セッションのローカルな記録を維持すべきである。 新しいサービス · セッションがスタートする場合は常に、 新しいセッシ ョン識別子を備えた新しいェントリが作られ、 セッションが終了する場 合には、 そのエントリは削除されて、 識別子は解放されて再利用可能と なる。 本実施例では、 フィールドは 2オクテットであり、 また、 識別子 は 1 6進数の値である。 なお、 端末にサポートされた他のタイプの識別 子の使用が可能なことは、 当業者にとっては明白である。 MT— IDフィー ルド （3 0 4 ) 及び Session— IDフィールド （ 3 0 6 ) は、 ホーム ·ネッ トワーク 'ォーソライザ （1 0 3 ) において、 サービス 'セッションを 一意に識別する。
また、 Address— Requestフィールド （ 3 0 7 ) は、 移動端末 （1 0 1 ) からのア ドレス割り付けの要求に関する情報を含んでいる。 本実施例 では、 図 4に示されるように、 複合した構造が使用されている。 この構 造の第 1のパートは、 Address— Typeフィールド （40 1) である。 これ は、 どのタイプのア ドレスが移動端末 （ 1 0 1 ) にサポートされている かを識別する。 このフィールドのサイズは 1オクテッ トであり、 可能な 値は次の通りである。
No_IP::=0x00;
Single— Stack— IPv4: :=0x01；
Single— Stack— IPv6— FullAddress: :=0x02;
Single— Stack— IPv6— Prefix: :=0x03;
Dual一 Stack— IPv4一 Preferred: :=0x04;
Dual_Stack_IPv6_Preferred_FullAddress::=0x05;
Dual— Stack— IPv6一 Preferred— Prefix: :=0x06
さらなるタイプがサポートされ、 他の数が使用され得ることは、 当業 者にとっては明白である。 また、 この構造の第 2のパートは、
Suggestion— Lengthフィールド （40 2) である。 このフィールドは、 次のフィールド Address— Suggestionsフィールド （40 3) の長さを示 している。 Addi'ess_Suggestionsフィールド （40 3) は、 移動端末 （ 1 0 1 ) が割り当てられることを望むア ドレスを列挙する。 例えば、 進 行中のセッションが、 あるア ドレスを使用している場合、 そのセッショ ンが中断されないように同一のァドレスが割り当てられることが重要で ある。 列えば、 Address— Suggestionsフィーノレド （40 3) は、 ァドレ スのリス トである。 リス ト内の各エントリは、 例えば、 I P v 4や I P V 6などのァドレスのタイプを示す 1ォクテツ トのタイプ . フィ一ノレド から始まり、 実際のア ドレスがそれに続く。 端末によるア ドレス提示の 特徴をサポートしないホーム ·ネッ トワーク · ォーソライザ （ 1 0 3) では、 Suggestion— Lengthフィールド （40 2) 及び Address— Suggestionsフィールド （4 0 3 ) は、 暗黙のうちに無視され る。
また、 Address— Requestフィールド （3 0 7 ) の後には、
Tunnel— Requestフィールド （ 3 0 8 ) が存在する。 このフィールドは、 どのタイプのトンネルをサポートしているかを示すために、 移動端末 （ 1 0 1 ) によって使用される。 このフィールドの最初のオクテッ トは、 それ自体を含むこのフィールドの長さを示し、このフィールドの内容は、
2オタテツ トを占める各ェントリを持つリス トとすることが可能である c 各ェントリの最初のオタテツ トは、 移動端末 （1 0 1 ) がサポートする トンネル · タイプの識別子を含んでおり、 そのオクテッ トの値には、 次 のものが可能である。
ネッ トワーク トンネル 般的：: =0x01;
ネッ トワーク トンネル -- モ/くィノレ IPv4::=0x02;
クライアント トンネル -- 一般的：:二 0x04
クライアント ト ンネノレ - - モノくィノレ IPv4::=0x05;
クライアント ト ンネノレ - - モノくィノレ IPv6::=0x06;
トンネル無し：:—0x08
このフィールドで、 他のトンネルのタイプを定義して使用できること は、 当業者にとっては明白である。 また、 各エントリの 2番目のォクテ ッ トは、 トンネルの方向を示している。 このオクテッ トの可能な値は。 次の通りである。
トンネル -- 端末力 ら：: =0x01;
トンネル -- 端末に：: =0x02;
トンネノレ -- 双方向：:二 0x03;
リスト内の最初のェントリは、 移動端末 （1 0 1 ) の好ましいタイプ を示している。 また、 MT— Re que st_Aメッセージ （202 A) 内の次のフィールドは WLAN— IDフィールド （ 309) である。 これは、 ホーム 'ネッ トヮー ク .ォーソライザ （1 03) に対する WL ANを識別する情報を含んで おり、 これによつて、 ホーム 'ネッ トワーク · ォーソライザ （1 0 3) は、 位置に基づく決定を行ったり、 移動端末 （1 0 1) への位置に基づ くサービスを提供したりすることが可能となる。 WLAN_IDは、 認証手 続きや、 例えば I EEE 802ネッ トワークにおける S S I Dなどのァ クセス ' ポイント （1 05) からブロードキャス トされた情報から取得 可能である。 さらに、 移動端末 （1 01) のローカルの識別子も含まれ ている。 これは、 アクセス ' ポイント （1 05) が端末を識別するため のものである。
また、 最後のフィールドは、 Security— Field (3 1 0) である。 この フィールドは、 メッセージを保護するための情報を含んでいる。 このフ ィールドのために使用される正確なアルゴリズムは、 移動端末 （1 0 1 ) とそのホーム 'ネッ トワーク 'ォーソライザ （1 03) との間で交渉 される。 また、 これは、 ユーザの加入時間で決定されてもよく、 端末の S I M又は U S I Mカードに格納されてもよい。 また、 さらにソフ トゥ エア ·モジュールとして実施可能であり、 必要な場合には常にダウン口 一ドされるようにすることが可能である。
なお、 MT— Request— Aメッセージ （202A) 内のフィールドは、 上 述のような正確なシーケンスに従う必要はなく、 例えば、 実際には、 最 前部にフィールドの識別子を配置する限り、 任意の順にフィールド （3 04) からフィールド （ 309 ) を配置することが可能である。
実際には、 任意の適切なメカニズムを使用して、 リンク （1 0 1 1) を通じてメッセージを伝送することが可能である。 例えば、 I EEE 8 0 2. 1 1ネッ トワークでは、 I EEE 802. l xに定義される EA POLを使用し、 EAPメッセージとして実現することが可能である （ 非特許文献 1 4) 。
アクセス ' ポイント （1 0 5) がこのメッセージを受け取った場合に は、 Domain— Nameフィーノレド （ 3 0 3) からホーム ' ドメイン情報を 引き出し、 例えば、 DN Sの照会を行なうなど、 そのドメイン情報を利 用して、 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) のア ドレスを 取得することが可能である。 アクセス ' ポイント （1 0 5) は、 この情 報に従って、 対応するホーム 'ネッ トワーク ·ォーソライザ （ 1 0 3) にメッセージを転送する。 例えば、 WL ANがセントラル AAAサーバ を有する場合には、 アクセス ' ポイント （ 1 0 5) は、 AAAサーバに メッセージを直接転送する。 そして、 WL ANの AAAサーバはドメイ ン情報を解析し、 実際のホーム .ネッ トワーク . ォーソライザ （ 1 0 3 ) にメッセージを転送する。 なお、 アクセス ' ポイント （1 0 5) とホ ーム 'ネッ トワーク ·ォーソライザ （1 0 3) との間に、 安全なリンク が存在することを前提としており、 これは、 認証手続き （2 0 1 ) での 設定で可能となるか、 又は、 そのプロセスに由来するセキュリティの関 連付けを動的に設定することによって可能となる。
また、 アクセス ' ポイント （1 0 5) は、 メッセージ処理に参加する 必要がなく、 したがって、 メッセージを解析するためにスタック全体を 実施する必要がない。 それは、 単にメッセージ ' タイプを読み、
MT— Request— Bメッセージ （20 2 B) のステップとして示される再力 プセル化及び転送を行う必要があるだけである。 転送のために使用され るプロ トコルとしては、 任意の適切な AAAプロ トコル （例えば、 ダイ ァメータのための E A Pアプリケーション （非特許文献 1 5) や、 ダイ ァメータのための NA S R E Qアプリケーショ ン （非特許文献 1 6 ) ) が可能である。 それらのプロ トコルは、 認証を目的として、 アクセス - ポイント （ 1 0 5) において、 すでに利用可能である。 したがって、 メ ッセージ MT— Request— Aメッセージ （ 20 2 A) は、 終端点間の認証手 続き （20 1) と同様、 本質的には、 移動端末 （1 0 1) からホーム · ネッ トワーク ·ォーソライザ （1 0 3) にエンド ' トゥー 'ェンドで送 られる。
また、 図 5は、 ホーム ·ネッ トワーク ·ォーソライザ （1 0 3) の状 態マシンの実施例を示すものである。 ホーム 'ネッ トワーク ·ォーソラ ィザ （1 0 3) は、 初期状態 （5 0 1 ) から始まり、 遷移 （/intiateO) (500 1 ) で初期化 0 の処理を行ってアイ ドル状態 （5 0 2) に移 る。 初期化 0 プロセスは、 他のパックエンド 'サーバとの接続、 セキ ュリティの関連付けなどを確立するために必要なすべてのステップを含 んでいる。 実際には、設定に依存して他のプロセスが含まれ得ることは 、 当業者にとっては明白である。
ホーム 'ネットワーク ·ォーソライザ （ 1 0 3) 、 遷移 （5 0 02 ) でアクセス ' ポイント （ 1 0 5) 力 ら転送された MTJRequest_Bメッ セージ （20 2 B) を受け取った場合には、 メッセージ復号状態 （5 0 3) に遷移する。 図 6は、 メッセージ復号状態 （ 5 0 3 ) の実施例を示 すものである。 メッセージ復号状態 （5 0 3) では、 ホーム 'ネッ トヮ 一ク ·ォーソライザ（ 1 0 3)は、ステップ（6 00 1)で Domain_Name フィールド （ 30 3) によって識別されたキーを使用して、
MTJRequest— Bメッセージ （202B) 内のフィールドを復号する。 ステツ プ （6 00 2) において、 メッセージが破損されているカヽ 又は、 Security— Field (3 1 0) を使用して修正されていることを検知した場 合、 ホーム ·ネッ トワーク ·ォーソライザ （ 1 0 3) は、 ステップ （6 0 1 3 ) において、 不正なメッセージのフラグをセッ トし、 状態マシン は、 遷移 （5 004) でサービス却下状態 （5 04) に遷移する。 MT— Re que st— Bメ ッセージ （202 B) から、 ホーム ' ネッ トワーク •ォーソライザ （1 03) は、 ステップ （ 6003) において、 MT— ID フィールド （304) から端末の識別情報に関する情報を獲得すること が可能である。 この識別情報を使用して、 ホーム ·ネットワーク ·ォー ソライザ （1 03) は、 そのデータベースやバックエンド 'サーバ （例 えば、 3 GP Pネッ トワークの HS S) から、 ユーザの加入情報を検索 する。 また、 ホーム · ネッ トワーク ·ォーソライザ （1 03) は、 さら にステップ （6004) で、 Service— Requestフィ一ノレド （ 305 ) ら得られたサービス要求情報を解析する。 サービス要求は、 例えば、 帯 域幅、 遅れ、 不安定性など、 挿入される様々なサービス固有情報を含む ことが可能である。 ステップ （6005) において、 ホーム 'ネットヮ ーク ·ォーソライザ (1 03) 内では、 ユーザ加入情報を使用して、 ュ 一ザにサービスを与えないでおくべきかどうかに関する決定が下される。 ユーザの加入に基づいて、 要求されたサービスが与えられるべきではな いとされた場合、 ホーム ·ネットワーク 'ォーソライザ （1 03) は、 ステップ（ 60 1 3 )において、サービスを否定するフラグをセットし、 状態マシンは、 遷移 （5004) でサービス却下状態 （504) に遷移 する。 もしサービスが許される場合には、 ホーム 'ネットワーク ·ォー ソライザ （1 03) は、 ステップ （6007) において、 Session一 IDフ ィールド （ 306 ) において受信したセッショ ン識別子のサービスの端 末を求めて、 そのレコードを探索する。 同一セッション識別子を有する レコードが存在する場合には、 これがハンドオーバの要求であることを 意味し、 端末には同じア ドレスが割り当てられるべきである。 これによ り、 サービス ' セッションは中断されることがなくなる。 また、 レコー ドが存在しない場合には、 それは新しい要求であることを意味し、 ステ ップ （6008) において、 レコード ' エント リが生成され、 ホーム . ネッ トワーク .ォーソライザ （1 0 3) の格納部に格納されるか、 例え ば、 HS Sなどのバックエンド 'データベースが更新される。 ホーム ' ネッ トワーク .ォーソライザ （1 0 3) は、 さらにサービス情報を使用 して、 サービス ' プロバイダ ·ネッ トワーク （ 1 00 3) を識別し、 サ 一ビス 'プロバイダ 'ネッ トワーク 'サーバ （ 1 04) との接続がセッ ト - アップされる。
ステップ （6 0 0 9) において、 Address— Requestフィーノレド （3 0 7) から、 ホー 'ネッ トワーク 'ォ一ソライザ （ 1 0 3) は、 移動端 末 （1 0 1) が使用を望んでいるア ドレスを取得する。 なお、 ホーム . ネッ トワーク 'ォーソライザ （1 0 3) 力 S、 オペレータのポリシーやそ の他によって、 この機能をサポートしたくない場合、 この情報を暗黙に 無視することが可能である。 移動端末 （ 1 0 1 ) は、 ホーム .ネッ トヮ 一ク 'ォーソライザ （1 0 3) から割り当てられた最終的なア ドレスを 常に使用するべきである。 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) は、 要求されたサービスから、 ア ドレスが、 局所的に又はホーム - ネットワーク （ 1 00 2) 内で割り当てられるべき力 あるいは、 サー ビス . プロバイダ .ネッ トワーク （ 1 0 0 3 ) 内で割り当てられるべき かを決定する。 例えば、 ユーザが WL ANローカル 'サービスを利用す ることしか認められていなければ、 ァドレスは WL AN内で割り当てら れ、 一方、 VPNサービスに加入するユーザには、 その VPN内のアド レスを用いて割り当てられるべきである。
また、 ホーム 'ネッ トワーク 'ォーソライザ （1 0 3) は、 ステップ (6 0 1 0) で Tunnel— Requestフィールド （ 3 0 8) から、 移動端末 (1 0 1)にサポートされたトンネルのタイプを検索する。この情報は、 サービス提供のためにトンネルをセッ ト ·アップするために用いられる。 移動端末 （ 1 0 1) は、 1つ以上のトンネルのタイプを列挙し、 リス ト 中の最初のものを好ましいタイプのものとすることが可能である。 ホー ム .ネッ トワーク .ォーソライザ （1 0 3) は、 サービス · プロバイダ 'ネッ トワーク .サーバ （ 1 04 ) と共にチェックを行って、 どのタイ プを使用すべきであるか決定する必要がある。 なお、 例えば、 トンネル の方向などの付加的な情報が含まれてもよい。
ステップ （ 6 0 1 1 ) において、 ホーム 'ネッ トワーク · ォーソライ ザ （1 0 3) は、 WLAN一 IDフィールド （3 0 9) から、 移動端末 （1 0 1) が現在関係している無線 LANの識別情報を得る。 この情報を使 用して、 ホーム ·ネッ トワーク ·ォーソライザ （1 0 3) は、 対応する WL AN管理サーバ （1 0 2) を見つける。 なお、 ローミングの協定の —部として、 ホーム 'ネッ トワーク 'ォーソライザ （ 1 0 3) のデータ ベースにこの情報を格納することが可能であり、 また、 バックエンド ' サーバ （例えば HS S) からこの情報を引き出せるようにすることも可 能である。 サーバの情報を取得した後、 安全なリンクが確立される。 こ のリンクは、 以降のサービス ' メッセージ ' シグナリングのために使用 されるものである。
すべての情報を取得した後、 ホーム 'ネッ トワーク 'ォーソライザ （ 1 0 3) は、 Service— Reqeustメッセージ （20 3)及び 1^1^ー1¾(11½8 メッセージ （20 5) を作成し、 ホーム 'ネッ トワーク ' ォーソライザ ( 1 0 3) の状態マシンが待機状態 （5 04) に遷移する場合、 このメ ッセージが送り出される。
図 7は、 Service— Requestメッセージ （ 20 3) の実施例を示すもの である。 このメッセージは、 Home— Network— IDフィールド （7 0 1) から始まる。 このフィールドは、 移動端末 （1 0 1 ) のホーム 'ネッ ト ワーク識別子に関する情報を含み、 オペレータの名前や大きなネッ トヮ ークのサブシステムであり得る。 識別子はグローバルにユニークでなけ ればならず、 例えば 「network.operator.3gpp.org」 などのネッ トワーク の DNS名は、 この識別子の好適な候補である。 ホーム .ネッ トワーク 情報の存在によって、 サービス 'プロバイダ ·ネッ トワーク 'サーバ （ 1 04) は、 例えば、 ローミングの協定などのネッ トワーク · ポリシー を、 サービス要求に対して適用することが可能となる。 また、 ユーザの プロファイルはホーム ' ネッ トワーク （1 00 2) によって管理されて いる。 したがって、 ユーザ情報は、 サービス · プロバイダ 'ネッ トヮー ク ·サーバ （1 04) に送られるべきではないが、 サービスのよ りよい コントロールを可能にするため、 メッセージにユーザ . プライオリティ /グルーピング情報を付加することも可能である。 これは、 例えば、 「 goldmember. network. operator.3gpp.orgJ どのよつ (こ、 ホーム '不ッ トワーク識別子と関連付けられてもよい。 サービス · プロバイダ .ネッ トワーク .サーバ （1 04) は、 これを用いて、 サービスを与える場合 にユーザを差別化することが可能となる。
また、 次のフィールドは MT— IDフィールド （ 7 0 2) である。 このフ ィールドは、 移動端末 （1 0 1 ) の識別子に関する情報を含んでおり、 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) がサービス · トラツキ ングを行うために使用される。 識別子は端末の I MS I、 又は、 ホーム 'ネッ トワーク 'ォーソライザ （1 0 3) によって割り当てられ、 サー ビス 'セッショ ンに固有の一時的な I Dであり得る。なお、この情報は、 サービス 'セッションが終了するまで一貫性を有している必要がある。 また、 上記のフィーノレドに続いて、 Session_IDフィールド （ 7 0 3) が存在する。 これは、 端末によって割り当てられたセッション識別子で ある。 サービス 'プロバイダ 'ネッ トワーク ' サーバ （1 04) は、 現 在行われているすべてのセッショ ン情報の記録を保持すべきである。 し たがって、 セッション識別子がデータベースに存在する場合には、 それ は、サービス要求がハンドオーバによって引き起こされることを意味し、 また、 サービスの中断を避けるために同一のァドレス構成を使用すべき であることを意味する。 例えば、 セッショ ンが稼動している （ァクティ ブ） 場合、 サービス ·プロバイダ ·ネッ トワーク ·サーバ （1 04) は、 移動端末 （1 0 1 ) に対して同一のア ドレスを割り当てるべきである。 その結果、 コレスポンデント ' ノードとの通信はシグナリングなしで継 続されるようにすることが可能となる。
また、 Address— Re questフィールド （7 04) は、
Figure imgf000031_0001
ッセージ （2 0 2 A) のものと同一である。 この部分は、 例えば、 I P V 6などの割り当てるべきァドレスのタイプをサービス ·プロバイダ - ネットワーク ·サーノく (1 04) に示すものである。 さらに、
MT一 Request— Aメ ッセージ （ 20 2 A) の Address_Requestフィールド (30 7) と同様に、 移動端末 （ 1 0 1) によって要求されたァドレス を提供する。 なお、 サービス ' プロバイダ 'ネッ トワーク 'サーバ （1 04) がこの機能をサポートしたくない場合には、 この情報を無視すれ ばよい。 また、 ホーム 'ネッ トワーク ' 才ーソライザ ( 1 0 3) によつ てサービス ' プロバイダ 'ネッ トワーク （ 1 0 0 3) からアドレスを割 り当てられる必要がないと決定された場合には、 このフィールドは省略 されてもよレ、。
Service— Specフィールド （70 5) は、 複合したフィールドであり、 ユーザの加入情報に基づいてホーム 'ネットワーク ·ォーソライザ （ 1 0 3) から要求される特定の要件に関する情報を含んでいる。 このフィ 一ルドの可能な実施例 （データ構造 1) は、 以下に示される。
struct Service一 Spec
u一 long bitrate_avgJ
u一 long bm'ate一 max; int deliver— order;
int MTU— size;
double delay i
double jitter;
int priority^
int service— direction;
int QoS— type
struct timeval start— time;
struct timeval end— time;
}；
この属性のうち、 bitrate— avg及び bitrate— maxは、 要求されたサービ スを保証するビッ ト · レート及び最大のビッ ト · レートである。 また、 deliver一 orderの属性は、 配送が順番に行われるかどうかを示すものであ る。 また、 MTU— sizeは、 サービスのために転送される最大のデータ . ユニッ ト 'サイズを特定するものである。 また、 delayと； jitterのフィー ルドは、 サービスのためのいくつかの基本的な Q o Sの属性を指定する ものである。 また、 priorityの属性は、 このサービスのためのデータ · トラフィックの取り扱い優先度を示すものである。 また、
service— directionの属†生は、 サービスが一方向か双方向かを示すもので ある。 また、 QoS_typeの属性は、 例えば Di Serv、 あるいは R S V Pな どを備えた InterServサ一ビスなどのサービスを提供するために用いら れる Q o Sのスキームを示すものである。 また、 start_time及び end_timeは、 サービスの開始時間及ぴ終了時間を示すものである。 サー ビス .プロバイダ ·ネッ トワーク .サーバ （ 1 0 4 ) は、 この情報を用 いて、 サービスのためのリソースのスケジュールを決めることが可能で ある。 なお、 実際に実施される際の構造においては、 サービスに固有の 他の属性が含まれてもよいことは、 当業者にとっては明白である。 また、 Service— Specフィールド （70 5) の後には、 Tunnel— Specフ ィールド （ 70 6) が存在する。 このフィールドはトンネル情報を含ん でおり、 MT— Request— Aメッセージ （20 2 A) の Tunnel— Requestフ ィールド （3 0 8) と同様だが、 いくつかの特別な情報が付加されてい る。 例えば、 ネッ トワーク ' トンネル 'エントリに関しては、 WLAN の終端点が提供され、 端末のトンネルに関しては、 データ暗号化のため に、 セキュリティ · キーを付加することが可能である。
また、 Service— Requestメッセージ （2 0 3) の最後のフィーノレドは、 Security_Field ( 7 0 7) である。 このフィールドは、 ホーム ' ネッ ト ワーク 'ォーソライザ （1 0 3 ) とサービス · プロバイダ 'ネッ トヮー ク 'サーバ （ 1 04) との間のセキュリティの関連付けを用いて、 メッ セージ全体を保護するために使用される。 なお、 ここで使用される正確 なアルゴリズムは、 実際の実施形態に依存する。
なお、 Service Re questメッセージ （2 0 3 ) 内のフィールドが記述 された順序である必要がないことは、 当業者にとっては明白であり、 実 際には、 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) 及ぴサービス 'プロバイダ 'ネッ トワーク .サーバ （1 04) は、 シグナリングの最 適化のために、 任意の適切な順序の交渉を行うことも可能である。
サービス ' プロバイダ 'ネッ トワーク 'サーバ （ 1 04) は、
Service_Requestメッセージ （20 3) を受け取った後、 サービス · ァ ドレス管理 （2 04) 手続きを行なう。 この手続きでは、 サービス . プ 口バイダ ·ネッ トワーク .サーバ （1 04) 、 Session— ID ( 7 0 3 ) に含まれていたセッション識別子を求めて、 そのデータベースの探索を 行う。 同一の移動端末 （1 0 1 ) のセッショ ン識別子が存在する場合、 サービス · プロバイダ 'ネッ トワーク ·サーバ （1 04) は、 例えば、 MTのア ドレス、 サービスの詳細など、 その記録内のすべての情報をコ ピーし、 それを返答メッセージとしてホーム 'ネットワーク · ォーソラ ィザ （1 0 3) に直接返信する。
また、 セッショ ン識別子が存在しない場合には、 サービス · プロバイ ダ 'ネッ トワーク 'サーバ （1 04) は、 そのデータベースの指標 （ィ ンデッタス） として、 新しいセッション識別子を使用して新しいェント リを作成する。 サービス ■ プロバイダ 'ネッ トワーク ·サーバ （1 04 ) は、 Address— Requestフィールド （7 04) をチェック し、 このフィ 一ルドで指定されたア ドレスのタイプに基づいて、 移動端末 （1 0 1 ) に適切なア ドレスを割り当てる。
サービス ' プロバイダ 'ネッ トワーク 'サーバ （1 04) は、 ホーム ネッ トワーク ·ォーソライザ ( 1 0 3) からの Service— Specフィ一ノレ ド （ 70 5) をチェックし、 要求されたサービスがサポートされない場 合には、 失敗を示すメッセージが、 ホーム 'ネッ トワーク 'ォーソライ ザ （ 1 0 3) に送られる。 なお、 失敗の原因を特定するために、 あるェ ラー . コードを使用することも可能である。 また、 Service— Specフィー ノレド （ 70 5) 内の所定の属性が、 サービス . プロバイダ .ネッ トヮー ク （1 00 3) の現在の能力を超える場合には、 サービス . プロバイダ 'ネッ トワーク .サーバ （1 04) は、 新しいセッ トの属性で、 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) とやり取りを行おうと試みる ことも可能である。 これは、 サービス · プロバイダ ·ネッ トワーク ·サ ーバ （1 04) によって提案された値に修正された Service— Specフィー ノレド （ 7 0 5) を有する同一の Service— Requestメッセージ （2 0 3) 力 S、 ホーム 'ネッ トワーク 'ォーソライザ （1 0 3) に送り返されるこ とによって達成される。
また、 サービス ' プロバイダ 'ネッ トワーク 'サーバ （1 04) は、 Tunnel— Sepcフィールド （ 7 0 6 ) をチェックし、 一致する トンネノレの タイプを求める。 複数の一致があるかもしれないが、 サービス · プロバ イダ 'ネッ トワーク . サーバ （1 0 4) は最初に一致したものを選択す べきである。 ネッ トワークに基づく トンネルのタイプに関しては、 サー ビス ' プロバイダ 'ネッ トワーク 'サーバ （1 0 4) は、 返答メッセー ジ内にトンネルの終端点の情報を用意する必要がある。 クライアントに 基づく トンネルに関しては、 サービス ·プロバイダ ·ネッ トワーク · サ ーバ （ 1 0 4) は、 トンネルのタイプに固有の情報を用意し、 返答情報 にこの情報を含ませる。 例えば、 モパイル I P V 6のタイプのスキーム に関しては、 サービス ' プロバイダ 'ネッ トワーク ' サーバ （1 0 4) は、 移動端末 （ 1 0 1 ) にホーム ' エージェントを割り当てる必要があ る。 また、 返答メッセージ内に、 あるセキュリティ情報を含ませること も可能である。 なお、 方向性の情報 （例えば、 一方向、 両方向） も トン ネル情報のフィールドに付加されてもよい。
サービス 'プロバイダ ·ネッ トワーク 'サーバ （1 0 4) は、
Service— Replyメッセージ ( 2 0 5 ) を用いて、 ホーム 'ネッ トワーク •ォーソライザ （1 0 3 ) に対して返答を行う。 Service— Replyメッセ ージ （ 2 0 5) には、 図 7に示されるような Service— Requestメッセ一 ジ （ 2 0 3 ) と同様の構造を使用することが可能である。
Home—Network— IDフィールド （7 0 1 ) 、 MT— IDフィールド （7 0 2 ) 、 及び、 Session— IDフィールド （ 7 0 3 ) の内容は、 対応する
Service— Requestメッセージ （2 0 3) から直接コピーされる。 なお、 これらのフィールドは、 複数の端末のためにシグナリングのリンクが再 利用される場合に、要求及び返答メ ッセージのペアを一致させるために、 ホームネッ トワークォーソライザ （ 1 0 3) によって使用される。
Service— Replyメッセージ (2 0 5 ) 内の Address— Requestフィーノレド (7 04) の内容は、 移動端末 （ 1 0 1) に割り当てられたァ ドレスを 含んでおり、 それは、 バイ トでフィールドの長さを示す最初のオタテツ トを有するァ ドレスのエント リのリス トであり得る。 フィールドの次の 部分はァドレスのリストであり、 実際のァドレスを伴うア ドレスのタイ プを示す 1オクテッ トを有している。 ワイルドカードのアドレスも許可 されており、 例えば、 ア ドレス ' フィールドがすべて 0で満たされる場 合には、 WL ANのローカルのメカニズム （例えば I P V 6 自動割り付 け （非特許文献 1 7) や DHC Pを使用して、 移動端末 （1 0 1 ) がァ ドレスを形成することを示している。
また、 Service— Replyメッセージ （20 5) 内の Service— Specフィー ノレド （ 70 5) の内容には、 サービス ' プロバイダ 'ネッ トワーク ' サ ーバ （ 1 04) によって同意された属性が含まれている。 すべての属性 がサービス . プロバイダ 'ネッ トワーク ·サーバ （ 1 04) によって承 認される場合には、 対応する Service— Requestメッセージ （ 2 0 3 ) 内 の Service— Specフィールド （7 0 5) と同一である。 一方、 同一でない 場合には、 サービス ·プロバイダ ·ネッ トワーク ·サーバ (1 04) は、 ホーム ·ネッ トワーク ·ォーソライザ （1 0 3) に対して、 対立した提 案を行っていることになる。
また、 Service— Replyメッセージ （20 5) 内の Tunneし Specフィーノレ ド （ 7 06 ) は、 サービス · プロバイダ 'ネッ トワーク 'サーバ （ 1 0 4) によって選択されたトンネルの設定を含んでいる。 このフィールド の正確な内容は、 トンネルのタイプに依存しており、 クライアントに基 づく トンネル · タイプが選択された場合には、 ただ 1つのセッティング のみが必要となる。例えば、もしモパイル I P v 6が同意されていれば、 このフィールドには、 移動端末 （1 0 1) に割り当てられたホーム ·ェ 一ジヱントのァドレス及びバインディングアップデート認証のためのセ キユリティ · キーなどが含まれることとなる。 また、 Address一 Request ブイールド （ 704) 內のァ ドレスは、 移動端末 （1 0 1) のホーム . アドレスとして使用される。 また、 ネッ トワークに基づく トンネルのタ イブが選択される場合、 このフィールドには、 例えば、 終端点ア ドレス やトンネル識別子、 サポートされる トンネルのタイプのそれぞれに関し て必要となるすべての詳細な情報が含まれることとなる。
Service_Requestメッセージ （2 0 3) と並行して、 ホーム 'ネッ ト ワーク ·ォーソライザ （1 0 3) は、 WLANサーバ （1 0 2) に対し て、 WLAN_Requestメッセージ （2 0 6) を送信する。 このメッセージ は、 WLAN内のサービス提供に必要な設定の取り決めを行うためのも のである。 図 8には、 このメッセージの実施例が示される。
WLAN_Re questメッセージ （ 2 0 6 ) は、 Service— Requestメッセ一 ジ （20 3) のよ うに、 Home— Network— IDフィールド （8 0 1) 及び MT— IDフィールド （8 0 2) の 2つのフィールドを含んでいる。
Home— Network一 IDフィールド （8 0 1 ) は、 カロ入者のホーム 'ネッ ト ワークの識別子を含んでおり、 あるネッ トワーク · ポリシ一がサービス 提供に適用される場合に、 WL ANサーバ （ 1 0 2) に渡される。 また、 MT_IDフィールド （80 2) は、 移動端末 （1 0 1) の位置を追跡する ために使用され.る。 例えば、 移動端末 （ 1 0 1 ) の下位レイヤの識別子 (例えば、 MACア ドレス） と関連するアクセス · ポイントの識別子を 利用することが可能である。
また、. Address— Allocフィールド （8 0 3) は、 移動端末 （1 0 1) に WL ANのローカル . ァドレスを割り当てる必要があるかどうか示す フラグと、 使用されるべきァドレスのタイプである。 ホーム 'ネッ トヮ ーク 'ォーソライザ （1 0 3) は、 選択されたトンネル · スキームに基 づいて、 ローカル ' アドレスが必要か否かを決定する。 実際には、 例え ば、 次の定義を用いて、 このフィールドの最初のオクテッ トによって、 ァドレス割り付けが必要であるか否かが示される。
No— Allocation: :=0x00;
Single— Stack— IPv4::=0x01;
Single— Stack一 IPv6— FullAddress::=0x02;
Single— Stack— IPv6JPrefix::=0x03;
Dual— Stack— IPv4— Preferred::=0x04;
Duaし Stack— IPv6— Preferred— FullAddress::=0x05;
Dual— Stack_IPv6— Preferred— Prefix: :=0x06
なお、 このメッセージの実際の実施において、 他の値が使用可能であ ることは、 当業者にとっては明白である。
Service— Supportフィールド （8 0 4 ) は、 W L A N内でサービス提 供をサポートするために必要な属性をすベて含んでいる、 複合したフィ 一ルドである。 実際の内容は、 サービスの特定であり、 このフィールド の内容の例は、 データ構造 1に説明されたものである。
また、 Tunnel_Setupフィールド （ 8 0 5 ) も複合したフィールドであ り、 Service—Requestメ ッセージ （ 2 0 3 ) 内の Tunneし Specフィー/レ ド （ 7 0 6 ) と同様のフォーマッ トが使用される。
また、 WLANJRequestメッセージ （2 0 6 ) の最後のフィーノレドは、 Security—Field ( 8 0 6 ) である。 このフィールドは、 メ ッセージ全体 を完全に保護するために、 セキュリティの関連付けが使用される。 この フィールドの計算のために使用されるアルゴリズムは、 実際の実施形態 に依存している。
WLAN_Requestメッセージ （ 2 0 6 ) を受け取った後、 W L A Nサー ノ （ 1 0 2 ) は、 W L A Nサービス · 了ドレス管理 （2 0 7 ) を実行す る。 例えば、 ローカルの I P V 6ア ドレスの割り付けが、 ホーム . ネ 、ソ トワーク .ォーソライザ （1 03) によって要求された場合には、 WL ANサーバ（1 02)は、適切なネッ トワーク 'セクションを見つけて、 端末に I P V 6ア ドレスを割り当てる。 なお、 必要ならば、 さらに WL ANサーバ .（1 02) は、 ゲートウェイの更新を行う （すなわち、 WL AN'のファイア · ウォールに新しいアドレスの割り付けを行う） 。 これ により、 移動端末 （1 0 1) は、 この割り当てられたローカル · ァ ドレ スを使用して、 サービスにアクセスすることが可能となる。
WLANサーバ （102) は、 さらにローカルの承認コントローノレを 実行するために、 Service一 Supportフィーノレド （804) 内の情幸艮を使 用する。 サービス ' プロバイダ 'ネットワーク 'サーバ （ 1 04) と同 様に、 もし任意の属性が WL ANの現在のキャパシティーを超える場合 には、 WL ANサーバ (1 02) は、 ホーム 'ネッ トワーク ' ォーソラ ィザ （1 03) との間で、 例えば、 ビッ ト · レートの縮小やサービスの 時間間隔の変更など、 サービスの詳細に係る新しいセッ トの取り決めを 試みる。
もし、 クライアン トに基づく トンネルのスキームが、 ホーム ' ネッ ト ワーク 'ォーソライザ （1 03) によって選択された場合には、 WLA Nサーバ （1 02) は、 特別な設定を行う必要がない。 一方、 ネッ トヮ ークに基づく トンネル ' スキームが使用される場合には、 WLANサー ノ （1 02) は、 MT— IDフィールド （802) からの情報を用いて、 ト ンネルの終端点を識別する必要がある。
WLANサーバ （1 02) は、 WLAN一： Replyメッセージ （ 208 ) を 用いて、 WLAN_Requestメッセージ （206) への返答を行う。
WLAN_Replyメッセージ （208) には、 図 8に示される
WLAN— Requestメッセージ （206) と同様の構造が利用される。
Home— Network— IDフィールド （80 1) と MT IDフィールド （802 ) は、 対応する WLAN_Requestメッセージ （206) から直接コピーさ れる。 これらのフィールドは、 要求及び返答メッセージのペアを一致さ せるために、 ホーム 'ネッ トワーク 'ォーソライザ （1 03) によって 使用される。
また、 WLAN— Replyメッセージ （208) 内の Address— Allocフィー ルド （ 803) には、 移動端末 （1 0 1) に割り当てられた WL ANの ローカル · 了 ドレスの情報が含まれている。 MT一 1¾31½81_ メッセージ ( 202 A) 内の Address— Requestフィールド （ 307) に定義される ように、 このフィールドの最初のオクテッ トは、 ア ドレスのタイプを示 している。 このフィールドの次に続く部分には、 移動端末 （1 0 1) に 割り当てられる実際のア ドレスが含まれており、 例えば、 I P v 6ア ド レスが割り当てられる場合には、 最初のオクテッ トは 0x02となり、 次の 32オタテツトには、 実際の I P V 6ァドレスが含まれる。
また、 WLAN_Replyメッセージ （208) 内の Service— Supportフィ 一ルド （804) には、 WLAN— Requestメッセージ （ 206 ) に定義さ れるサービスの属性の情報が含まれている。 もし、 WLANがこれらの サービスの属性を受け入れた場合には、 WLANサーバ （1 02) は、 WLAN_Requestメッセージ （206) から、 それらを直接コピーする。 一方、 WLANサーバ （1 02) がその属性を受け入れることができな かった場合、 WLAN一 Replyメッセージ （208) 内に新しい値をセッ ト した属性を加えて、 新たな提案を送信する。
また、 WLAN— Replyメッセージ （208) 内の Tunnel_Setupフィー ルド （ 805) は、 移動端末 （1 01) へのトンネルの情報である。 こ こには、 最初のオクテッ ト内で使用される トンネルのタイプ、 及び、 次 のオクテッ トでトンネルのタイプに固有のデータが示されている。 例え ば、 モパイル I P V 6がデータ ' トラフィックに対して使用される場合 には、 このフィールド内にはトンネルのタイプのみが存在し、
Address— Allocフィールド （8 0 3) のァ ドレスが移動端末 （ 1 0 1 ) の気付ア ドレスとして使用される。 一方、 モパイル I P V 4が使用され る場合には、 このフィールドには、 最初のオクテッ トにトンネルのタイ プが含まれ、 移動端末 （1 0 1 ) に割り当てられるフォーリ ン 'エージ ェントのァ ドレスが後続する。
Service— Replyメッセージ （2 0 5) 及び WL AN一: Re plyメッセージ （ 208) の受信後、 ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) は、 WLANサーバ （ 1 0 2) 及びサービス · プロバイダ 'ネッ トワーク ' サーバ （1 04) からの情報を統合する。 もし、 Service_Specフィール ド （70 5) 又は Service— Supportフィールド （ 70 6) が、
Service一： Requestメッセージ （20 3) 又は ¥1^ 1^ 11681:メッセージ
(20 6) 内のものとは異なっている属性の値を含んでいる場合には、 サービスの詳細を再度取り決める必要がある。 このとき、 ホーム .ネッ トワーク 'ォーソライザ （1 0 3) は、 サービス ' プロバイダ 'ネッ ト ワーク . サーバ （ 1 04) 又は W LANサーバ （1 0 2) によって提案 された新しい値をチェックし、 もし、 これらの新しい値を受け入れるこ とが可能ならば、 SPN— Configメッセージ （2 1 0) 及び WLAN— Config メッセージ （2 1 1) を用いて、 新しい設定の承認を行う。
Service— Requestメ ッセーン (20 3) 、 Service—Replyメ ッセーシ ( 20 5) と WL AN— Re que stメ ッセージ （20 6) 、 WLAN— Reply messagge ( 20 8 ) とのメッセージのペアは、 時間的な相関性を有して いない。 すなわち、 それらは並行に行われる力 、 ホーム 'ネッ トワーク -ォーソライザ（1 0 3)の実施にそれぞれ依存して 1つずつ行われる。 例えば、 WLANサーバ （1 0 2) との接続がアイ ドル状態ならば、 ホ ーム 'ネッ トワーク 'ォーソライザ （ 1 0 3) は、 Service一 Requestメ ッセージ （20 3) の代わりに^]^ ：^ー1^(11½81:メッセージ （2 0 6 ) を 発送する決定を行うことが可能である。
また、 再度やり取りが必要な場合に、 新しいサービス ·パラメータを 確認するために、 ホーム ·ネッ トワーク ·ォーソライザ （1 03) から サービス · プロバイダ 'ネッ トワーク ·サーバ （1 04) に対して、 SPN_Configメッセージ （2 1 0) が送られる。 なお、 SPN— Configメッ セージ （21 0) には、 Service— Requestメッセージ （203) と同一 のメッセージ ' フォーマッ トが使用される。 また、 もし同一のメッセ一 ジ . フォーマツ トを使用しない場合には、 例えば、 Address_Requestな どのいくつかのフィールドが省略されることがある。
また、 必要に応じて、 トンネリングの情報が付加されてもよい。 例え ば、 クライアントに基づく トンネル （例えば、 モパイル I P) が使用さ れる場合には、 WLANサーバ （1 02) によって割り当てられる移動 端末 （1 01) の気付ァ ドレスが、 TunnelJRequestフィールド （ 30 8) に挿入される。 また、 ネッ トワークに基づく トンネルが使用される 場合には、 WL ANのトンネルの終端点ァドレスやポート番号などが、 このメッセージで転送される。 ·
また、 WLAN_Configメッセージ （2 1 1) は、 同様の目的で利用さ れるものであり、 ホーム .ネットワーク . ォーソライザ （1 03) は、 必要に応じて、 このメッセージを使用して、 WLANサーバ （1 02) に新しい設定を確認してもらう。 また、 さらに、 この情報は、 トンネル の情報を転送するために用いられることも可能である。 例えば、 ネッ ト ワークに基づく トンネルが使用される場合には、 サービス · プロバイダ ' ネッ トワーク （ 1003) の トンネルの終端点ア ドレスやポート番号 などが、 このメッセージで WL ANサーバ （1 02) に転送され、 その 後、 WL ANサーバ （ 102) は、 コレスポンデント ·ノードに対して、 トンネルをセッ ト · アップするよう命ずる。 一方、 クライアントに基づ く トンネルが使用される場合には、 端末のア ドレスがこのメッセージに 含まれ、 その結果、 WLANはデータ ' トラフィックのためにファイア
. ゥ ί"ールを開く ことが可能となる。
なお、 サービス 'セッションが終わったときに、 移動端末 （ 1 0 1 ) に害 ijり当てられたリソースを無効にするために、 ホーム ·ネッ トワーク
•ォーソライザ （1 0 3) によって、 これらの 2つのメッセージ、 SPN_Configメッセージ （2 1 0) 及ぴ WLAN一 Configメッセージ （2 1
1) が使用可能であることは、 当業者にとっては明白である。 例えば、 移動端末 （1 0 1 ) がもはや WL AN内に存在しないことを、 ホーム - ネットワーク 'ォ一ソライザ （1 0 3) が検知した場合には、 それは、 すべて 0にセッ トされた Service— Supportフィールド （8 04) を含む WLAN—Configメッセージ （2 1 1) を出すことができる。 WLANサ ーバ （1 0 2) は、 この種のメッセージを受け取った後、 移動端末 （1 0 1) に割り当てられたリソースをすベて解放し、 他の適切な動作を実 行する。
ホーム 'ネッ トワーク ·ォーソライザ （1 0 3) は、 MT— Request一 B メッセージ （2 0 2 B) に対する返答として、 MT一 1¾ 1 _；8メッセージ ( 2 1 2 B) を送る。 このメッセージは、 アクセス ' ポィント （1 0 5 ) 、 又は、 他の付随した装置によって、 メッセージ MT—Reply_Aメッセ ージ （ 2 1 2 A) として、 移動端末 （1 0 1) に転送される。 なお、 ]\^1_ 6 1 _ メッセージ （2 1 2 A) 及び MT— Reply— Bメッセージ （2 1 2 B) は、 同一の内容及ぴフォーマッ トを有している。 ホーム .ネッ トワーク ·ォーソライザ （1 0 3) と移動端末 （ 1 0 1 ) との間のネッ トワーク 'エレメントは、 これらのメッセージの内容にアクセスせず、 また、 アクセス ' ポイント （1 0 5) は、 単にメッセージ全体を再カプ セル化して、 それを転送する。 MT一; Reply__Aメッセージ （2 1 2 A) 又 は MT— Reply Bメッセージ （2 1 2 B) は、 移動端末 （1 0 1) とホー ム ·ネッ トワーク ·ォーソライザ （1 03) との間で共有されるセキュ リティの関連付けによって暗号化される。 なお、 MT— Reply— Aメッセー ジ （21 2 A) は、 対応する MT— Request— Aメッセージ （202 A) へ の返答であり、 アクセス ' ポイント （105) は、 転送すべき移動端末 (10 1) を把握することが可能である。
また、 WLANサーバ （1 02) が MT— Reply— B— message ( 21 2 B ) のパス上にある場合には、 そのメッセージに WLAN_Configメッセ一 ジ （2 1 1) を乗せて運ぶことが可能である。 例えば、 WLANサーバ (1 02) 、 WL AN内のダイァメータを用いて、 移動端末 （1 0 1 ) に MT— Reply_Bメッセージ （2 1 2 B) を転送する A A Aサーバであ る場合には、 MT—Reply_Bメッセージ （2 1 2 B) は、 ダイァメーター EAP— Answer AVPにカプセル化可能である。 一方、 同じメッセ一 ジ內の別の AV Pに WLAN— Configメッセージ （2 1 1) がカプセル化 されてもよい。 また、 他の転送プロ トコルが利用される場合でも、 同じ ようなスキームが使用可能であることは、当業者にとっては明白である。 また、 MT— Rep ly_Aメッセージ （2 1 2A) は、 図 3に示される _16(11168し メッセージ （202 A) と同一の構造を有している。 Message— Typeフィールド （30 1) は、 MT— Request一 Aメッセージ （
202 A) のものと同一のフォーマッ トを有しており、 このメッセージ が要求ではなく、返答であることを示すための整数が使用される。また、 Message— Lengthフィールド （302) は、 Message— Typeフィールド （
30 1) を含むメッセージの長さの合計を示すものである。 また、 MT一 Reply— Aメッセージ （ 2 1 2 A) 内の Domain— Nameフィールド （ 303) 及び MT— IDフィールド （ 304) は、 MT— Request Aメッセ一 ジ （20 2A) 内のものと同一である。 なお、 シグナリングを最適化す るため、 実際には、 これらのフィールドが省略可能であることは、 当業 者にとっては明白である。
また、 MT—Reply_Aメッセージ （ 2 1 2 A) 内の Service— Requestフ ィールド （ 305) は、 ユーザの加入情報に基づいて、 ホーム 'ネッ ト ワーク .ォーソライザ （1 03) によってセッ トされるサービス特定情 報を含むように使用される。 例えば、 もしユーザが I MSサービスを要 求した場合には、 P— C S CFア ドレスが利用可能である。 なお、 この フィールドが、サービスの提供に必要な他の情報を含んでもよいことは、 当業者にとっては明白である。 また、 このフィールドの正確なフォーマ ッ トは、 サービスに依存している。
また、 MT— Reply一 Aメッセージ ( 21 2 A) 内の Session_IDフィ一ノレ ド （306) は、 MT— Request— Aメッセージ （ 202 A) から直接コピ 一されるが、 移動端末 （1 0 1) によって要求されない場合、 実際には それを省略することが可能である。
また、 MT_Reply_Aメッセージ （ 2 1 2 A) 内の Address— Requestフ ィールド （ 307) は、 移動端末 （1 0 1) に割り当てられるァ ドレス を含んでいる。 これは、 ソース ' ア ドレスとしてサービス ' アプリケー ションによって使用されるべきものである。 このフィールドの最初のォ クテツ トはァドレスのタイプであり、 実際のアドレスが後続する。 例え ば、 もし I P v 6ア ドレスのプリフィックスが割り当てられれば、 最初 のォクテツ トは 0x03となる。 また、 次の 32オタテツ トは、 実際の IPv6 ア ドレスを形成するために移動端末 （1 0 1) によって使用されるプリ フィックス情報を含んでおり、例えば、 WL ANゲートウエイア ドレス、 DN Sサーバァドレスなどの他のァドレス情報を含むことも可能である。 これらの属性は、 上記のア ドレス情報に後続する。 また、 すべて 0であ るワイルドカードの値は、 移動端末 （1 0 1) 力 s、 実際のア ドレス情報 を得るために、 ロー力ノレのステー トレス （Stateless) のメカニズムを使 用すべきであることを示している。
また、 ！^ _16 _ メッセージ （2 1 2 A) 内の Tunnel— Re que stフィ ールド （ 308) は、 移動端末 （1 0 1) によって要求されるサービス にアクセスするためのトンネリングの設定を含むものである。 これは、 トンネルのタイプに依存し、 このフィールドの最初のオクテッ トは、 使 用される トンネルのタイプを示している。
例えば、 クライアントに基づく トンネルのタイプにモパイル I P V 6 が使用される場合には、 MTJRequest— Aメッセージ （ 202 A) でトン ネルのタイプが定義されるように、 その値は 0x06となる。 タイプの属性 に続いて、 WL ANによって割り当てられる気付ァドレス及びホーム · エージェントのア ドレス、 そして、 必要であればセキュリティ ' キーが 存在する。 Address_Requestフィールド （307) 内のア ドレスは、 端 末に割り当てられたホーム ' ア ドレスとなる。
また、ネッ トワークに基づく トンネルのタイプが使用された場合には、 タイプ属性に続いて、 トンネルのローカルの終端点ア ドレスと、 移動端 末 （1 01) が安全に終端点と通信を行うためのセキュリティ · キーと が存在する。
MT— Reply— Aメッセージ （ 2 1 2 A) 内の WLAN— IDフィールド （ 3 0 9) は、 MT— Request— Aメッセージ （202 A) から直接コピーされ る。 なお、 シグナリングを最適化するため、 実際には、 それを省略する ことが可能である。
また、 MT— Reply— Aメッセージ （2 1 2 A) の Security— Field (3 1 0) は、 メッセージ全体を完全に保護するために使用され、 移動端末 （ 1 0 1) とホーム 'ネッ トワーク ·ォーソライザ （1 03) との間のセ キユリティの関連付けが使用される。 なお、 ここでは、 MT_Request— A メッセージ （2 0 2 A) のものと同一のアルゴリズムを使用すべきであ る。
]\^_1^ _ メッセージ （2 1 2A) を受け取った後、 移動端末 （ 1 0 1) はすべての必要な情報を検索して、 それに従って構成を行い、 こ の設定を使用して、 実際のサービス . セッショ ン （2 1 3) を開始する ことが可能となる。
実際には、 移動端末 （1 0 1) は、 例えば、 ビデオス トリーミング · セッションと一緒に Voice-over-IPセッションを行うなど、 レヽくつ力 のサ 一ビスを同時に要求することが可能である。 すなわち、 シグナリング内 に、 異なるサービス · プロバイダ ·ネッ トワークを関係付けることが可 能である。 同一のメッセージ内にいくつかのサービスの要求をまとめる シナリオにおいて、 上記と同一のメカニズム及びメッセージの構造を使 用することが可能である。 例えば、 MT_Request一 Aメッセージ （2 0 2 A) 内に、 Service— Requestフィールド （3 0 5) 、 Session一 IDフィー ノレ ド （ 3 0 6 )、 Address— Requestフィ一ノレ ド （ 3 0 7 )、 Tunnel— Request フィールド （ 3 0 8) の複数のセッ トを存在させることが可能である。 これらの 4つのフィールドはグループ化され、 移動端末 （1 0 1) によ つて要求された各サービスは、 これらの 4つのフィールドの 1グノレープ を含んでいる。 例えば、 MT— Re quest一 Aメッセージ （20 2 A) 力 S
Voice-over-IPセッション及ぴビデオス トリーミング ·セッションを要求 した場合には、列挙された 4つのフィールドのグループが 2つ存在する。
Figure imgf000047_0001
ッセージ （20 2A) と同じ内容を含んでいる MTJRequest— Bメッセージ （20 2 B) を受け取った後、 ホーム .ネッ トワーク ·ォーソライザ （1 0 3) は、 移動端末 （ 1 0 1) によって要 求される 1つの特定のサービスに対応した、 これらの 4つのフィールド の各セッ トから情報を検索する。 ホーム 'ネッ トワーク .ォーソライザ (1 03) は、 単一のサービスの要求に対して、 上記のように要求され たサービスの各々のためのシグナリングを実行する。 例えば、 ホーム . ネッ トワーク ·ォーソライザ （ 1 03 ) は、 I MSサブシステム及ぴス トリーミング ·サービスを提供するネッ トワークの両方に、
Service_Re questメッセージ （20 3) を送る。 また、 異なる各サービ スに係る WLAN_Requestメッセージ （ 206 ) 力 S、 同一の WL ANに送 られる。 ホーム 'ネッ トワーク 'ォーソライザ （1 03) は情報を集め、 ただ 1つのメッセージを送ることが可能である。 同一の WL ANに多数 の 1^ —1^911681:メッセージ （ 206 ) を送る必要がある場合には、 そ れらのうちの 1つだけが、 ローカルのァドレスの割り付けの要求を行う 必要がある。
ホーム 'ネッ トワーク ·才ーソライザ (1 03) は要求されたサービ スの順序に従って、 1つの MT_Reply_Bメッセージ （2 1 2 B) にすベ てのサービス情報を統合し、 アクセス ' ポイント （1 05) を介して、 移動端末 （1 01) に転送する。 その後、 移動端末 （1 0 1) は統合さ れた MT—Reply_Aメッセージ （ 21 2 A) 内の情報を用いて、 それ自体 のァドレス構成を行うことが可能となる。
なお、 移動端末 （1 01) が並行して多数のサービスを要求した場合 には、 異なるサービス 'プロバイダ 'ネッ トワークからその端末に異な るア ドレスが割り当てられる可能性があり、 さらに、 異なるサービス - セッションにおいて異なる トンネルが設定される可能性がある。 このシ ナリオでは、 特別な中間層プロセッサ （mid-layer processer) が必要と なる。 Session_IDフィールド （ 306 ) で使用されるようなサービス - セッション識別子が、 中間層プロセッサによって使用されて、 ア ドレス 及ぴトンネルの設定が多重化される。 移動端末 （10 1) 内の中間層プロセッサは、 異なるサービス 'セッ ションにおけるァドレス及びトンネル情報のローカルのデータベースを 保持している。 サービス ' セッションが移動端末 （1 0 1) で生成され た場合、 中間層プロセッサはそのための識別子を作成する。 これは、 MT— Request一 Aメ ッセージ （ 202 A) の Session一 IDフィールド （ 30 6) 内で使用されるセッショ ン識別子である。 ア ドレス及びトンネル情 報をすベて含む ！^^ — メッセージ （21 2 A) を受け取った後、 中間層プロセッサは、 セッション識別子によって指標化 （インデックス ィ匕） されたすべての情報を含むデータベース内に、 新しいエントリを作 成する。 サービス ' アプリケーションが、 新しい接続セッションを開始 する必要がある場合には、 中間層プロセッサに対してセッション識別子 が設定されたリクエス トを送り、 中間層プロセッサは、 このセッション 識別子を用いて、 データベースから、 対応するア ドレス及ぴトンネル情 報を検索する。 ア ドレス及びトンネル情報は、 例えば、 I Pレイヤなど の通常のスタックによって使用され、 接続を行うために、 ソケッ トなど の適切なバインディングが作られる。
なお、 実際には、 例えば、 WLANサーバ （1 02) などのようなコ ントローラのない WL ANが存在可能であることは、 当業者にとっては 明白である。 このような場合には、 移動端末 （1 0 1) はア ドレスの割 り付け及ぴトンネルの設定のために、 WL ANのローカルのメカニズム を使用しなくてはならない。 ホーム ·ネッ トワーク ·ォーソライザ （1 0 3) は、 MT— Reply一 Aメッセージ （21 2 A) 内の Address_Request フィールド （307) 及び Tunnel— Re questフィールド （ 308) をす ベて 0にセッ トし、 これによつて、 移動端末 （1 0 1) に対して、 例え ば、 DHCP V 6、 M I P V 6などの WLANメカニズムを使用してァ ドレス構成を行うよう強いることになる。 また、 ある場合では、 移動端末 （1 0 1 ) 、 WL AN内のサービス 登録の取り消しを望むことがある。 サービスの登録抹消を行う場合でも 上記のメカニズムを使用することが可能であることは、 当業者にとって は明白である。 移動端末 （1 0 1 ) は、 サービスの終了を示す特別の値 力 Service— Requestフィールド （ 3 0 5) に設定された MTJRequest— A メッセージ （2 0 2 A) を送出することが可能である。 例えば、 Servic e一 He questフィーノレト (3 0 5ノ ί 「tei'minate.i'equest.IMS.ioo.bar.op erator-name.operatorgroup.gprs」のよつな [直 'sむこと 可首 である。 なお、 「request (要求)' 」 キーワードの前の 「terminate (終了） 」 が 、 「request (要求） 」 キーワードの後に付けられている AP Nによって 示されたサービスを終了するためのフラグである。 また、 MT_Request —Aメッセージ （20 2 A) の Session— IDフィールド （ 3 0 6 ) は、 終了 するサービスのセッション識別子に設定可能であり、 このタイプの MT_ Request— Aメッセージ （20 2 A) では、 Address— Requestフィールド ( 3 0 7) 及び Tunnel一 Requestフィールド （ 3 08 ) を省略すること が可能である。
ホーム ·ネッ トワーク 'ォーソライザ （1 0 3) は、 通常と同様に、 MTJRequest— Aメッセージ （ 2 0 2 A) の処理を行い、 その
Service— Requestフィールド （ 3 0 5 ) 内に 「終了」 のキーワードを見 つけた場合には、 Session— IDフィールド （ 3 0 6 ) からサービス · セッ ション識別子を取り出す。 そして、 ホーム ·ネッ トワーク ·ォーソライ ザ （1 0 3) は、 サービス登録時に作られたセッション · エント リを探 すため、 そのデータベースを探索する。 このセッション ' エント リは、 例えば、 割り当てられたア ドレス、 トンネル設定などのサービスの設定 に関する情報を格納している。 この情報を用いて、 通常と同様に、 ホー ム 'ネッ トワーク 'ォーソライザ （1 0 3) は、 サービス ' プロバイダ 'ネッ トワーク ·サーノく ( 1 04) に Service一 Requestメッセージ （2 0 3) を送り、 WLANサーバ （ 1 0 2) に WLAN_Re questメッセージ (20 6) を送る。 これらのメッセージにおいて、 Service— Specフィー ルド （ 7 0 5) 及ぴ Service— Supportフィールド （8 04) は、 すべて 0にセッ トされる。
サービス ' プロバイダ 'ネッ トワーク 'サーバ （ 1 04) と W L A N サーバ （ 1 0 2) は、 通常通り、 メッセージを処理し、 Service— Specフ ィールド （ 7 0 5) 及び Service— Supportフィールド （8 04) がすべ て 0に設定されているのを読んで、 サービス終了の要求であることを把 握する。 これらの 2つのサーバは、 サービス登録時に作られたサービス ' セッション ' エントリを探すため、 それらのデータベースを検索し、 例えば、 I Pア ドレスや予約している帯域幅などのサービス ·セッショ ンに対応するリソースを解放する。
ホーム 'ネッ トワーク · 才ーソライザ ( 1 0 3) 力 S、 サービス . プロ バイダ 'ネッ トワーク （ 1 00 3) 及び WLANから通知を受け取った 後、 MT— Reply— Aメ ッセージ （ 2 1 2 A) 力 移動端末 （1 0 1) に返 される。 このメッセージは、 サービスを終了し、 予約されていたリソー スが解放されたことを通知するものである。 この MT_Reply— Aメッセー ジ （2 1 2A) では、 Service— Re questフィーノレド （ 3 0 5) に、 その 結果に関する情報が含まれている。 例えば、 このフィールドにおいて、 次のィ直 「： removed. request. IMS. foo.bar.operator-name. operator-group. gprs」 を使用することが可能である。 ここでは、 「request」 キーワード の前の 「removed」 キーワードが、 サービスの登録抹消の成功を示して いる。 なお、 例えば、 「removedJ キーワードの後に情報を付加するな ど、 特別な情報を含めてもよいことは、 当業者にとっては明白である。 また、 移動端末 （ 1 0 1 ) へのサービス提供の過程において、 ポリシ 一 . コントロールを含ませることも可能である。 例えば、 GPR Sイン ターフェースを使用する端末は、 1 4 9Kb p sのアクセス ' レートが 与えられている。 この端末が WL ANに入った場合、 その端末は、 同じ サービスにアクセスするために WL ANィンターフェースを使用するよ う移行する。 WLANは、 はるかに高いエア ' インターフェース帯域幅 を提供するので、 端末がより高いアクセス ' レート （例えば、 IMb p s ) を享受することを切望する。 移動端末 （ 1 0 1 ) に対して、 このよ り高いサービス · レートを与えるためには、 ポリシー ' コントローノレ . フレームワークが起動され、 例えば、 ゲートウェイ ' フィルタなど、 対 応するポリシー設定を修正する必要がある。 上記の例では、 例えば、 G G S Nなどの制御点が、 GPR Sインターフェースを使用してサービス を始める場合には、 GG SNは、 端末のサービスのために 1 4 9 K b p sの帯域幅のみを予約すればよい。 また、 移動端末 （ 1 0 1) 力 再び WL ANサービスを利用して、 サービス ' セッショ ンを登録する場合、 ポリシ一'サーバは、 GG S Nの設定を 1Mb p sに修正すべきである。 なお、 他の種類の設定ゃコントロール · ノードがポリシー · コントロー ルに含まれることは、 当業者にとっては明白である。
この種のポリシー ' コントロールは、 ユーザの加入情報に従って行わ れるべきであり、 したがって、 ホーム 'ネッ トワーク ' ドメイン内で行 われるべきである。 本発明は、 サービスの要求及びア ドレス （トンネル の設定） を扱うためにホーム ·ネッ トワーク · ォーソライザ （ 1 0 3) を使用するものである。 したがって、 それは、 ポリシー ' コントロール 決定のために必要な情報をすベて有しており、 ホーム 'ネッ トワーク · ドメィンのポリシー ·サーバにホーム 'ネッ トワーク ·ォーソライザ （ 1 0 3 ) から、 こうした情報を渡すことが可能である。 ポリシー .サー バは、 このとき、 例えば、 GG SNなどのコレスボンディング . ノード を適宜動作させるよう操作可能とするポリシー ' コントロール 'インタ 一フェースを利用することが可能である。 さらに、ポリシー.サーバは、 ポリシー ' コントロール · フレームワークを使ったサービス提供に関連 する他のネッ トワークに通知を行うことも可能であり、 例えば、 ホーム 'ネッ トワーク ' ドメインのポリシー 'サーバは、 W L A N内のポリシ 一 ·サーバに対して、 新しいアクセス · レートの制限を通知することが 可能であり、 その結果、 WL ANポリシー 'サーバは、 ローカルの承認 管理機構を適宜調節することが可能となる。
また、 図 9は、 ホーム ·ネッ トワーク ·ォーソライザ （ 1 0 3) とポ リシー ·サーバとの間で使用されるメッセージの実施例を示すものであ る。 このメッセージは、 Operationフィールド （9 0 1) 力 ら始まる。 このフィールドは、 ポリシー ·サーバによって行われる動作を示すもの であり、 可能な値は次の通りである。
Install::=0x01
Remove ::=0x02
Figure imgf000053_0001
ホーム ·ネッ トワーク ·ォーソライザ （1 0 3) が移動端末 （1 0 1 ) から新しいサービス 'セッショ ンの要求を受け取った場合、 Operation フィールド （9 0 1 ) 内に 「Install」 の値を使用する。 また、 移動端末 ( 1 0 1) がサービス · セッションを終了する場合には、 ホーム .ネッ トワーク 'ォーソライザ （1 0 3) は、 Operationフィールド （9 0 1 ) 内に 「： Removed」 の値を使用する。 また、 移動端末 （ 1 0 1 ) からの サービスの要求がアクティブなサービス 'セッションを参照している場 合には、 「Update」 の値を使用する。 なお、 実際の実施においては、 他 のタイプの値の使用が可能であることは、当業者にとっては明白である。 また、 2番目のフィールドは、 MT IDフィールド （ 9 0 2) である。 このフィールドは、移動端末（1 0 1)の識別子を含んでおり、例えば、 モパイルのユーザの IMS Iが使用可能である。
また、 3番目のフィールドは、 MT_Locationフィールド （ 903) で ある。 このフィールドは、 例えば、 端末が所定の WL ANに存在する場 合には、 2倍のアクセス · レートを提供するなど、 位置に基づくサービ スのポリシーを検索するために、 ポリシー ·サーバによって使用される ものである。 このフィールドは、 例えば、 MT_Request_Aメッセージ （ 202 A) の WLAN_IDフィールド （ 309) 力 らの WL AN識別子を 含むものである。
また、 次のフィールドは、 MT_Serviceフィールド （904) である。 このフィールドは、 移動端末 （1 0 1) によって、 どのような種類のサ 一ビスがアクセスされているかを示すものである。 さらに、 このフィー ノレドが、 サービス ' セッション情報を含むことも可能である。 このフィ ールドの内容の例としては、 APNにセッション識別子を加えたものが 可能である。
また、 次のフィールドは、 Tunnel— Settingフィールド （ 905) であ る。 このフィールドは、 WLAN内で移動端末 （1 01) によって使用 される トンネルの設定を示すものである。 このフィールドの内容はトン ネルのタイプであり、 トンネルの終端点ア ドレス、 ポー ト番号などが後 続する。 なお、 正確なフォーマッ トは、 トンネルのタイプに依存する。 また、 使用される トンネルのタイプは、 MT_Request_Aメッセージ （2 0 2 A) の Tunnel— Requestフィールド （ 308) で定義されたもので ある。
また、 メッセージの最後のフィールドは、 MT_Addressフィールド （ 9 06 ) である。 このフィールドは、 W LAN内で移動端末 （1 0 1) によって使用されるア ドレスを含むものである。 これは、 ポリシー 'サ ーバによって使用され、 サービスにアクセスするフィルタリングの規則 を設定することが可能となる。
なお、 実際には、 メッセージ ' フィールドが上記ほど正確な順序で並 ベられる必要がないことは、 当業者にとっては明白である。 また、 各フ ィールドは、 さらに、 本実施例に記述されない他の情報を含むことが可 能である。 産業上の利用可能性
本発明は、 W L A N相互接続において、 端末のア ドレス割り当てを管 理する管理方法を提供する。 本発明の適用によって、 移動端末には、 そ れが要求したサービスとその加入情報に基づいてァドレスの割り当てが 行われ、 ローカル ' リ ソースへのアクセスを必要とせずに、 ア ドレス管 理が実行可能となる。 さらに、 本発明は、 W L A N相互接続における ト ンネルの設定のコントロール方法を提供する。 ここでは、 移動端末は、 サービス許可と同時にネットワーク及びクライアントに基づく トンネル の設定をサポートすることができる。 さらに、 本発明は、 ポリシー - コ ントロール . フレームワークでの相互接続の方法を提供する。 提供され るインターフェースを用いることによって、 サービス許可、 ア ドレス割 り当て、 及び、 トンネル設定情報をポリシー ·サーバに伝播することが 可能となり、 よりょく端末にサービスを配信するために適切な動作を行 うことが可能となる。 すべての方法において、 端末とそのホーム · ドメ イン 'サーバとの 1回の往復メッセージの交換で、 ア ドレス管理、 トン ネルの設定及びサービスの許可を達成することが可能である。 したがつ て、 貴重なシグナリングの時間や帯域幅が節約される。

Claims

請 求 の 範 囲
1. 移動端末と、 前記移動端末のユーザ加入情報にアクセス可能 であり、 前記移動端末のホーム ' ドメイン内に配置されているコント口 ーラとの間におけるセキュリティ保護された終端点間サービス許可シグ ナリングをァドレスの管理のために利用することによって、 前記コント ローラがサービス許可情報に基づくア ドレス割り当ての管理を行うこと が可能であり、 ローカル WL ANアクセス制御に基づくことなく、 WL AN相互接続において前記移動端末のァドレス割り当ての管理を行うた
2. 移動端末と、 前記移動端末のユーザ加入情報にアクセス可能 であり、 前記移動端末のホーム ' ドメイン内に配置されているコント口 ーラとの間におけるセキュリティ保護された終端点間サービス許可シグ ナリングをトンネルの管理のために利用することによって、 前記コント ローラがサービス許可情報に基づく トンネル管理を行うことが可能であ り、 ローカル WL ANアクセス制御に基づくことなく、 WLAN相互接 続において前記移動端末のトンネルの管理を行うための、二
3. 移動端末と、 前記移動端末のユーザ加入情報にアクセス可能 であり、 前記移動端末のホーム ' ドメイン内に配置されているコント口 ーラとの間におけるセキュリティ保護された終端点間サービス許可シグ ナリ ングをァドレス及びトンネルの管理のために利用することによって、 前記コントローラがサービス許可情報に基づくァドレス割り当て及ぴト ンネルの管理を行うことが可能であり、 ローカル WL ANアクセス制御 に基づくことなく、 WL AN相互接続において前記移動端末のァドレス 割り当て及びトンネルの管理を行うための、:
4 . 前記ローカル W L A Nアクセス制御処理に由来したシグナリ ング · メッセージの保護及び暗号化のためのセキュリティ連携を利用す ることによって、 前記 W L A N相互接続の前記シグナリング . メッセ一 ジを保護するよう構成されている請求項 1カゝら 3のいずれか 1つに記載
5 . 前記移動端末のドメイン情報を利用することによって、 前記 移動端末のホーム · ドメイン内の前記コントローラの位置情報を特定す るよう構成されている請求項 1カゝら 3のいずれか 1つに記載のシステム c
6 . 前記移動端末がその ドメイン情報をメッセージ内に埋め込み、 前記移動端末と前記コントローラとの間に存在する中間ノードが前記ド メイン情報を参照して、 前記ドメイン情報に基づいて前記メッセージを 転送することによって、 前記中間ノードが、 前記コントローラに前記メ ッセージを転送するためのァドレスを決定するよう構成されている請求 項 1から 3のいずれか 1つに記載のシステム。
7 . i . ア ドレス割り当て要求及びア ドレス割り当て応答に、 所定のワイルドカード値を使用することによって、 前記移動端末におけ るステートレスなァドレス構成をサポートし、
ii . 前記ァドレス割り当て要求及び前記ァドレス割り当て応答に、 ァ ドレスのタイプのリス トを入れることによって、 前記移動端末におけ るア ドレスの異なるタイプをサポートし、 '
iii . ァ ドレス管理情報にァ ドレスのプリフィ ックスを入れることに よって、 前記移動端末に対する複数のァドレスの割り当てをサポートす るよう構成されている請求項 1又は 3に記載のシステム。
8 . i . 前記移動端末が、 前記サービス . アクセス . セッショ ンを一意に識別する識別子を生成し、
ϋ . 前記移動端末と前記コントローラとの間のア ドレスに係るメッ セージに、 前記サービス ' アクセス ' セッショ ンの識別子を入れること によって、 ァドレス割り当て処理と前記サービス · アクセス ·セッショ ンとの関連付けを行い、
iii . 前記コントローラが、 前記移動端末の前記サービス . アクセス 'セッションで利用される前記ァドレスをトレースし、
iv . 前記コントローラが、 前記サービス · アクセス ' セッショ ンの 識別子を利用して、 前記サービス ' アクセス 'セッションにおいて前記 移動端末によって使用されるァドレスを検索するよう構成されている請 求項 1又は 3に記載のシステム。
9 . 前記コントローラが、 前記サービス ' アクセス ' セッション で使用される前記移動端末のァドレスの格納管理を行うためのバックェ ンド 'サーバを利用するよう構成されている請求項 8に記載の
1 0 . 前記コントローラは、
i . 前記移動端末の識別子と前記サービス ' アクセス . セッション の識別子とを指標とするエントリが前記コントローラのレコード内に存 在しない場合には、 前記移動端末の識別子と、 前記サービス ' アクセス - セッションの識別子とを指標とする新たなェントリを作成し、
ϋ . 前記サービス ' アクセス ' セッショ ン用に前記移動端末に割り 当てる前記ァ ドレスが設定された前記ェントリを格納し、
iii. 前記移動端末が前記サービス 'アクセス .セッションを終了し た場合には、 格納されている前記ェント リを削除して、
前記コントローラが、 前記 W LAN相互接続における前記移動端末の 前記ァドレス構成を保持するよう構成されている請求項 8に記載のシス テム。
1 1. i . サービス許可メッセージにおいて、 ア ドレス割り当 て要求とそれに対応するサービス · アクセス要求とをグループ化するこ とによって、 複数の異なるサービス 'アクセス 'セッションに対する複 数のァドレスの割り当てをサポートし、
ϋ - 前記コントローラが、 前記移動端末の異なるサービス . ァクセ ス要求に基づいて、 異なるア ドレス構成を取得して、
前記移動端末における同時サービス · セッションが可能となるよう構 成されている請求項 1又は 3に記載のシステム。
1 2. i . 前記移動端末が、 対応する前記ア ドレス構成と共に 前記サービス ' アクセス ' セッショ ン情報を格納するためのローカルデ ータベースを保持し、
ϋ - サービス ' アクセス · セッションの識別子を使用して、 ァ ドレ スを多重化することによって、 前記移動端末が、 異なるサービスにァク セスするために異なるァドレスを使用して、
複数のサービス ' セッションに対する複数のァドレス構成をサポート するよう構成されている請求項 1 1に記載の V
1 3. i . 前記ポリシー 'サーバとのインターフェースを設定 することによって、 前記コントローラが、 前記移動端末にサービスを提 供するためのポリシー構成を修正できるようにし、
ii . W L A N内の前記移動端末にサービスを提供するためのコント 口一ノレ · ノ一ドに対するポリシー ' コント口一ノレ · フレームワークを通 じたポリシー ·シグナリングを、 前記コントローラに開始させることに よって、前記コントロール 'ノードに関するポリシー設定を適応させて、 ポリシー設定の調整が可能となるよう構成されている請求項 1から 3 のいずれか 1つに記載の 1 4 . 前記サービスの許可を行うサービス 'ォーソライザと、 前 記ポリシー ·サーバとの間の情報交換に利用されるメッセージのフォー マツ 卜力 s、
i . 前記ポリシー ·サーバで行われる動作を示すオペレーション識 別子部と、 .
ϋ . 前記移動端末の識別子を含む移動端末識別子部と、
iii . 前記移動端末に対して、 前記移動端末の位置に基づくポリシー を適用するための前記移動端末の位置情報を含む移動端末位置情報部と、 iv . 前記サービスのタイプと、 必要に応じて前記サービスのセッシ ョン識別子とを含む移動端末サービス情報部と、
V . 前記サービスにアクセスするために、 前記移動端末によって利 用されるトンネル設定情報を含むトンネル設定情報部と、
vi . 前記サービスにアクセスするための前記移動端末の前記ァドレ スを含むァドレス情報部とを、
有する請求項 1 3に記載のシステム。
1 5 . i . 移動端末のユーザ加入情報にアクセス可能であり 前記移動端末のホーム · ドメイン内に配置されているコントローラに対 して、 前記移動端末が、 セキュリティ保護された終端点間のサービス許 可要求と共に、 ア ドレス管理要求を送信するステップと、
ϋ . 前記コントローラが、 前記サービス許可要求及び前記ユーザ加 入情報に基づいて、 前記移動端末が前記サービスへのアクセスを行うた めのァドレスを割り当てるステップと、
iii . 前記コントローラが、 セキュリティ保護された終端点間サービ ス許可シグナリングを用いて、 ァドレス管理情報を前記移動端末に送信 するステップとを、
有し、 ローカル W L A Nアクセス制御に基づくことなく、 W L A N相 互接続において前記移動端末が前記サービスにアクセスするためのアド レス割り当ての管理を行うための方法。
1 6 . i . 移動端末のユーザ加入情報にアクセス可能であり、 前記移動端末のホーム · ドメイン内に配置されているコントローラに対 して、 前記移動端末が、 セキュリティ保護された終端点間のサービス許 可要求と共に、 トンネル管理要求を送信するステップと、
ϋ . 前記コントローラが、 前記サービス許可要求及び前記ユーザ加 入情報に基づいて、 前記移動端末が前記サービスへのアクセスを行うた めのトンネル構成を決定するステップと、
iii . 前記コントローラが、 セキュリティ保護された終端点間サービ ス許可シグナリングを用いて、 前記トンネル構成情報を前記移動端末に 送信するステップとを、
有し、 ローカル W L A Nアクセス制御に基づくことなく、 W L A N相 互接続において前記移動端末が前記サービスにアクセスするためのトン ネルの管理を行うための方法。
1 7 . i . 移動端末のユーザ加入情報にアクセス可能であり、 前記移動端末のホーム · ドメイン内に配置されているコントローラに対 して、 前記移動端末が、 セキュリティ保護された終端点間のサービス許 可要求と共に、 ァ ドレス及ぴトンネル管理要求を送信するステップと、 ϋ - 前記コントローラが、 前記サービス許可要求及ぴ前記ユーザ加 入情報に基づいて、 前記移動端末が前記サービスへのアクセスを行うた めのァドレス及びトンネル構成を決定するステップと、
iii . 前記コントローラが、 セキュリティ保護された終端点間サービ ス許可シグナリングを用いて、 前記ァ ドレス及び前記トンネル構成に係 る情報を前記移動端末に送信するステップとを、
有し、 ローカル W L A Nアクセス制御に基づくことなく、 W L A N相 互接続において前記移動端末が前記サービスにアクセスするためのアド レス割り当て及びトンネルの管理を行うための方法。
1 8 . 前記ローカル W L A Nアクセス制御処理に由来したシグナ リング ' メッセージの保護及び暗号化のためのセキュリティ連携を利用 することによって、 前記 W L A N相互接続の前記シグナリング · メッセ ージを保護する請求項 1 5から 1 7のいずれか 1つに記載の方法。
1 9 . 前記移動端末のドメイン情報を利用することによって、 前 記移動端末のホーム · ドメイン内の前記コントローラの位置情報を特定 する請求項 1 5から 1 7のいずれか 1つに記載の方法。 2 0 . 前記移動端末がそのドメイン情報をメッセージ内に埋め込 み、 前記移動端末と前記コントローラとの間に存在する中間ノードが前 記ドメィン情報を参照して、 前記ドメィン情報に基づいて前記メッセー ジを転送することによって、 前記中間ノードが、 前記コントローラに前 記メッセージを転送するためのア ドレスを決定する請求項 1 5から 1 7 のいずれか 1つに記載の方法。
2 1 . 前記移動端末によって要求される前記サービスを提供する ネッ トワーク内のァドレス管理エンティティと前記コントローラとの間 で、 前記移動端末による前記サービスへのアクセスに利用されるァドレ スの交渉を行うステップをさらに有する請求項 1 5に記載の方法。
2 2 . i . 前記移動端末が、 前記コントローラに対して送信す るァドレス割り当て要求に、 特定のァドレスを入れるステップと、
ii . 前記移動端末からの前記ア ドレス割り当て要求と、 前記移動端 末によりアクセスされるサービスに係る情報とに従って、 使用される前 記ァドレスを前記移動端末に割り当てるステップとを、
有し、 前記移動端末におけるサービス中断を抑制する請求項 1 5に記 載の方法。
2 3 . i . 前記移動端末が、 前記トンネル要求メッセージに、 前記トンネルのタイプのリス トを入れるステップと、
ii . 前記移動端末及びコントローラが、 前記トンネル要求メッセ一 ジ及ぴトンネル構成メッセージに、 トンネルの方向に係る情報を入れる ステップとを、
有し、 複数のトンネルのタイプ及び方向をサポートする請求項 1 6又 は 1 7に記載の方法。
2 4 . 前記移動端末によって要求される前記サービスを提供する
•ネッ トワーク内の実際のトンネル終端点と前記コントローラとの間で、 前記移動端末による前記サービスへのアクセスに利用される トンネル構 成の交渉を行うステップをさらに有し、 前記移動端末の前記トンネル構 成の管理を行う請求項 1 6又は 1 7に記載の方法。
2 5 . i . 前記コントローラが、 前記移動端末による前記サー ビスへのアクセスに利用される トンネルを管理する前記 W L A N内のト ンネル管理エンティティと通信を行うステップと、
ii . 前記 W L A N内の前記トンネル管理エンティティが、 前記コン トローラとの通信結果に応じて、 前記トンネルを使用可又は使用不可と するステップとを、
さらに有し、 前記移動端末の前記トンネル構成の管理を行う請求項 1 6又は 1 7に記載の方法。
2 6 . 前記コントローラが、 前記 W L A N内の前記トンネル終端 点の識別及び構成を行うために、 前記 W L A N内のトンネル管理ェンテ ィティと通信を行うステップと、
前記コントローラが、 前記移動端末に前記サービスを提供するネッ ト ワーク内の前記トンネル終端点の識別及び構成を行うために、 前記ネッ トワーク内のトンネル管理エンティティと通信を行うステップとを、 さらに有し、 前記移動端末が前記サービスにアクセスするためのサイ ト間ネッ トワーク · トンネルの設定を行う請求項 1 6又は 1 7に記載の 方法。
2 7 . 前記コントローラ力 前記ユーザ加入情報を参照するため、 前記移動端朱のホーム ·ネットワーク内のバックェンド ·サーバとの通 信を行うステップを有する請求項 1 6又は 1 7に記載の方法。
2 8 . 前記移動端末によって使用されるメッセージのフォーマッ トが、
i . すべてのネッ トワーク · ノードがアクセス可能な前記移動端末 のホーム · ドメイン情報部と、
ϋ . 前記サービス要求を許可するノードのみがアクセス可能な前記 ユーザの識別情報部と、
iii . 前記サービス要求を許可するノードのみがアクセス可能な 1つ 以上のサービス許可要求を含むサービス要求情報部と、
iv . W L A N識別情報部と、
V . 前記サービス要求に対応する 1つ以上のァドレス要求を含むァ ドレス要求情報部とを、
有する請求項 1 5又は 1 7に記載の方法。
2 9 . 前記移動端末によって使用されるメッセージのフォーマツ トが、
i . 前記移動端末のホーム · ドメインの識別情報部と、
ii . 前記サービス要求を許可するノードのみがアクセス可能な前記 ユーザの識別情報部と、
iii . 前記サービス要求を許可するノードのみがアクセス可能な 1つ 以上のサービス許可要求を含むサービス要求情報部と、
iv . W L A Nの識別子を含む W L A N識別情報部と、
v . 前記サービス要求に対応する 1つ以上のトンネル構成要求を含 むトンネル構成要求情報部とを、 有する請求項 1 6又は 1 7に記載の方法。
3 0 . 前記コントローラによって使用されるメ ッセージのフォー マツ トが、
1 . 前記移動端末のホーム ·ネットワークの識別情報部と、
11 . 前記サービスの要求に関するサービス · セッションの識別情報 部と、
111 . 前記サービス要求における前記移動端末の識別情報部と、 IV . 1つ以上のサービス要求を含むサービス要求情報部と、
V . 前記サービス要求に対応する 1つ以上のァドレス構成要求を含 むァドレス構成要求情報部とを、
有する請求項 2 1に記載の方法 c
3 1 . 前記コン トローラによって使用されるメ ッセージのフォー マツ 卜力 、
前記移動端末のホーム ·ネットワークの識別情報部と、 前記サービスの要求に関するサービス ' セッションの識別情報 部と
Ή1 前記サービス要求における前記移動端末の識別情報部と、 IV . 1つ以上のサービス要求を含むサービス要求情報部と、 v . 前記サービス要求に対応する 1つ以上のトンネル構成要求を含 むトンネル構成要求情報部とを、
有する請求項 2 4に記載の方法。
PCT/JP2004/000176 2003-01-14 2004-01-14 Ｗｌａｎ相互接続におけるサービス及びアドレス管理システム及び方法 WO2004077754A1 (ja)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP04702063A EP1585270A4 (en) 2003-01-14 2004-01-14 WIRELESS LOCAL NETWORK INTERCONNECTION SERVICE, ADDRESS MANAGEMENT SYSTEM, AND METHOD
CA2512959A CA2512959C (en) 2003-01-14 2004-01-14 Service in wlan inter-working, address management system, and method
US10/541,447 US7610038B2 (en) 2003-01-14 2004-04-14 Service in wlan inter-working, address management system, and method
US12/559,468 US8081971B2 (en) 2003-01-14 2009-09-14 Service in WLAN inter-working, address management system, and method
US13/292,874 US8374580B2 (en) 2003-01-14 2011-11-09 Service in WLAN inter-working, address management system, and method
US13/737,366 US9055563B2 (en) 2003-01-14 2013-01-09 Service in WLAN inter-working, address management system, and method
US14/707,308 US9560521B2 (en) 2003-01-14 2015-05-08 Service in WLAN inter-working, address management system, and method
US15/409,914 US9986426B2 (en) 2003-01-14 2017-01-19 Service in WLAN inter-working, address management system, and method
US15/961,951 US10511961B2 (en) 2003-01-14 2018-04-25 Service in WLAN inter-working, address management system, and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003-6175 2003-01-14
JP2003006175A JP4270888B2 (ja) 2003-01-14 2003-01-14 Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US10541447 A-371-Of-International 2004-01-14
US10/541,447 A-371-Of-International US7610038B2 (en) 2003-01-14 2004-04-14 Service in wlan inter-working, address management system, and method
US12/559,468 Continuation US8081971B2 (en) 2003-01-14 2009-09-14 Service in WLAN inter-working, address management system, and method

Publications (1)

Publication Number Publication Date
WO2004077754A1 true WO2004077754A1 (ja) 2004-09-10

Family

ID=32923188

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/000176 WO2004077754A1 (ja) 2003-01-14 2004-01-14 Ｗｌａｎ相互接続におけるサービス及びアドレス管理システム及び方法

Country Status (7)

Country Link
US (7) US7610038B2 (ja)
EP (2) EP2512067B1 (ja)
JP (1) JP4270888B2 (ja)
KR (2) KR100999761B1 (ja)
CN (2) CN100405776C (ja)
CA (1) CA2512959C (ja)
WO (1) WO2004077754A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1633083A1 (en) * 2003-06-06 2006-03-08 Huawei Technologies Co., Ltd. A method of user access authorization in the wlan
US8116782B2 (en) 2007-02-28 2012-02-14 Hitachi, Ltd. Communication quality control system

Families Citing this family (102)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8996698B1 (en) * 2000-11-03 2015-03-31 Truphone Limited Cooperative network for mobile internet access
US7602795B1 (en) 2002-08-20 2009-10-13 Sprint Spectrum L.P. Method and system for identifying a mobile station to a content server
JP4270888B2 (ja) * 2003-01-14 2009-06-03 パナソニック株式会社 Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法
US7616647B1 (en) 2003-03-11 2009-11-10 Sprint Spectrum L.P. Method and system for wireless local number portability
US8543703B1 (en) * 2003-03-25 2013-09-24 Apple Inc. Method of tracking mobile user sessions
US7956032B2 (en) * 2003-12-03 2011-06-07 Novo Nordisk A/S Glycopegylated granulocyte colony stimulating factor
US7417970B2 (en) * 2004-06-02 2008-08-26 Interdigital Technology Corporation Configuring an interworking wireless local area network user equipment to access a 3GPP system
TW200607293A (en) * 2004-08-03 2006-02-16 Zyxel Communications Corp Method and system for dynamically assigning agent of mobile VPN
US7984149B1 (en) * 2004-08-04 2011-07-19 Cisco Technology, Inc. Method and apparatus for identifying a policy server
US8942227B1 (en) 2005-01-21 2015-01-27 Apple Inc. Enhanced filtering for an IP multimedia subsystem
US8260257B2 (en) * 2005-02-07 2012-09-04 Cisco Technology, Inc. Key distribution for wireless devices
US20060203774A1 (en) * 2005-03-10 2006-09-14 Nokia Corporation System, method and apparatus for selecting a remote tunnel endpoint for accessing packet data services
KR100656079B1 (ko) 2005-03-23 2006-12-11 에스케이 텔레콤주식회사 홈 네트워크 기반의 디지털 액자 서비스 제공 방법
KR100667502B1 (ko) * 2005-03-28 2007-01-10 주식회사 케이티프리텔 모바일 ｉｐ를 이용한 이동 노드의 가상사설망 접속 방법
US7801043B2 (en) * 2005-04-01 2010-09-21 Interdigital Technology Corporation Method and apparatus for admission control and resource tracking in a wireless communication system
US20060251101A1 (en) * 2005-04-25 2006-11-09 Zhang Li J Tunnel establishment
US7881198B2 (en) * 2005-04-25 2011-02-01 Telefonaktiebolaget L M Ericsson (Publ) Method for managing service bindings over an access domain and nodes therefor
US7724753B2 (en) * 2005-06-24 2010-05-25 Aylus Networks, Inc. Digital home networks having a control point located on a wide area network
US7792528B2 (en) 2005-06-24 2010-09-07 Aylus Networks, Inc. Method and system for provisioning IMS networks with virtual service organizations having distinct service logic
US7864936B2 (en) * 2005-06-24 2011-01-04 Aylus Networks, Inc. Method of avoiding or minimizing cost of stateful connections between application servers and S-CSCF nodes in an IMS network with multiple domains
US7672297B2 (en) * 2005-06-24 2010-03-02 Aylus Networks, Inc. Mediation system and method for hybrid network including an IMS network
US7561535B2 (en) * 2005-06-24 2009-07-14 Aylus Networks, Inc. System and method for providing dynamic call models for users as function of the user environment in an IMS network
US20060291412A1 (en) 2005-06-24 2006-12-28 Naqvi Shamim A Associated device discovery in IMS networks
US20060291487A1 (en) * 2005-06-24 2006-12-28 Aylus Networks, Inc. IMS networks with AVS sessions with multiple access networks
KR101268579B1 (ko) * 2005-08-26 2013-05-28 한국전자통신연구원 범용 이동 통신시스템망과 무선 근거리 통신망과의 서비스연속성을 위한 장치 및 방법
KR101268578B1 (ko) * 2005-08-26 2013-05-28 한국전자통신연구원 범용 이동 통신시스템망과 무선 근거리 통신망과의 서비스연속성을 위한 장치 및 방법
US20090206986A1 (en) * 2005-08-31 2009-08-20 Shingo Murakami method of presenting ims public user identify to rfid applications
US7917124B2 (en) 2005-09-20 2011-03-29 Accenture Global Services Limited Third party access gateway for telecommunications services
EP1764972B1 (en) 2005-09-20 2017-07-19 Accenture Global Services Limited Authentication and authorization architecture for an access gateway
US8730796B2 (en) * 2005-09-30 2014-05-20 Alcatel Lucent Providing radio access between cellular and internet protocol-based wireless communication networks
KR100719118B1 (ko) * 2005-10-27 2007-05-17 삼성전자주식회사 특정 영역에서의 디바이스 기능 제한 방법 및 시스템
US8694616B2 (en) 2005-10-28 2014-04-08 Accenture Global Services Limited Service broker integration layer for supporting telecommunication client service requests
US7920583B2 (en) 2005-10-28 2011-04-05 Accenture Global Services Limited Message sequencing and data translation architecture for telecommunication services
US7508794B2 (en) * 2005-11-29 2009-03-24 Cisco Technology, Inc. Authorizing an endpoint node for a communication service
KR101315479B1 (ko) * 2005-12-10 2013-10-07 한국전자통신연구원 서비스 플로우 식별자를 분산 관리하는 무선 통신 시스템및 그 시스템에서의 서비스 플로우 식별자 관리 방법
CN100403719C (zh) * 2006-02-10 2008-07-16 华为技术有限公司 一种虚链路建立方法及装置
EP1821488B1 (en) * 2006-02-15 2012-08-08 Alcatel Lucent Method and apparatus for providing session mobility
US8432899B2 (en) 2007-02-22 2013-04-30 Aylus Networks, Inc. Systems and methods for enabling IP signaling in wireless networks
US9026117B2 (en) 2006-05-16 2015-05-05 Aylus Networks, Inc. Systems and methods for real-time cellular-to-internet video transfer
US8611334B2 (en) 2006-05-16 2013-12-17 Aylus Networks, Inc. Systems and methods for presenting multimedia objects in conjunction with voice calls from a circuit-switched network
US8730945B2 (en) * 2006-05-16 2014-05-20 Aylus Networks, Inc. Systems and methods for using a recipient handset as a remote screen
US7852878B2 (en) 2006-08-01 2010-12-14 Samsung Electronics Co., Ltd. Apparatus and method for supporting establishment of network address of communication apparatus
FR2904913B1 (fr) * 2006-08-09 2008-09-26 Alcatel Sa Procede de gestion d'interfonctionnement pour le transfert de sessions de service multiples entre un reseau mobile et un reseau local sans fil, et equipement correspondant
US8094797B2 (en) 2006-08-31 2012-01-10 Accenture Global Services Limited Service provisioning and activation engines for system
US8131831B1 (en) * 2006-09-19 2012-03-06 At&T Mobility Ii Llc Centralized policy management framework for telecommunication networks
US8060620B2 (en) * 2006-10-05 2011-11-15 Microsoft Corporation Profile deployment using a generic format
US8245284B2 (en) * 2006-10-05 2012-08-14 Microsoft Corporation Extensible network discovery
CN101584166A (zh) * 2006-11-02 2009-11-18 迪吉福尼卡（国际）有限公司 产生用于ip语音通信的路由消息
MX2009005751A (es) 2006-11-29 2009-08-26 Digifonica Int Ltd Intercepcion de voz a traves de comunicaciones de protocolo internet (ip) y otras comunicaciones de datos.
JP5144679B2 (ja) * 2006-12-19 2013-02-13 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信ネットワークにおけるユーザアクセス管理
US8009628B2 (en) 2007-02-28 2011-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Private mobility management enhancements
US7852819B2 (en) 2007-03-01 2010-12-14 Meraki, Inc. Client operation for network access
WO2008116296A1 (en) 2007-03-26 2008-10-02 Digifonica (International) Limited Emergency assistance calling for voice over ip communications systems
US7856226B2 (en) * 2007-04-17 2010-12-21 Aylus Networks, Inc. Systems and methods for IMS user sessions with dynamic service selection
CN101296111B (zh) * 2007-04-29 2012-06-27 华为技术有限公司 自动实现管理设备和被管理设备链接的方法及系统
US8169968B1 (en) * 2007-05-10 2012-05-01 Rockstar Consortium Reducing communication silence when performing inter-technology handoff
US7848280B2 (en) * 2007-06-15 2010-12-07 Telefonaktiebolaget L M Ericsson (Publ) Tunnel overhead reduction
US20080317010A1 (en) * 2007-06-22 2008-12-25 Aylus Networks, Inc. System and method for signaling optimization in ims services by using a service delivery platform
CN101540995B (zh) * 2008-03-21 2011-06-08 华为技术有限公司 一种获取信息的方法、用户设备及网络侧设备
JP5178539B2 (ja) * 2008-04-04 2013-04-10 キヤノン株式会社 情報処理装置、情報処理装置の制御方法、セッション管理システム並びにプログラム
ES2371378T3 (es) * 2008-04-04 2011-12-30 Canon Kabushiki Kaisha Sistema de gestión de sesiones y método para controlar las mismas.
KR101065121B1 (ko) * 2008-05-23 2011-09-16 주식회사 케이티 인증과 보안 기능이 강화된 이동 중계 장치 및 이를 이용한패킷 데이터 송수신 방법 및 시스템
US8630234B2 (en) 2008-07-28 2014-01-14 Digifonica (International) Limited Mobile gateway
US20100034386A1 (en) * 2008-08-06 2010-02-11 Daintree Networks, Pty. Ltd. Device manager repository
KR101614945B1 (ko) * 2008-08-20 2016-04-25 삼성전자주식회사 홈 네트워크에서의 개인정보 보호 방법 및 장치
US8010085B2 (en) * 2008-11-19 2011-08-30 Zscaler, Inc. Traffic redirection in cloud based security services
CN101790150B (zh) 2009-01-23 2012-01-25 华为技术有限公司 一种更新接入点名称签约配置的方法及装置
CN101959172A (zh) * 2009-07-17 2011-01-26 中兴通讯股份有限公司 Ngn中身份标识和位置分离的附着方法及系统
US8559392B2 (en) * 2009-07-30 2013-10-15 Cisco Technology, Inc. Inter-technology handovers for wireless networks
US9674636B2 (en) * 2009-09-03 2017-06-06 Interactive Wireless Technologies Llc System, method and computer software product for providing interactive data using a mobile device
US9807819B1 (en) * 2009-09-04 2017-10-31 Sprint Communications Company L.P. Cross-technology session continuity
US8675566B2 (en) 2009-09-17 2014-03-18 Digifonica (International) Limited Uninterrupted transmission of internet protocol transmissions during endpoint changes
US8614976B1 (en) * 2010-03-29 2013-12-24 Sprint Spectrum L.P. Method and system for registering a nickname associated with a mobile node
US10204365B2 (en) 2010-07-07 2019-02-12 T-Mobile Usa, Inc. Managing service provider service options
US8280943B1 (en) 2010-07-07 2012-10-02 T-Mobile Usa, Inc. Managing service provider messaging
CN102377831B (zh) * 2010-08-17 2014-05-21 中国移动通信集团公司 一种策略控制实体地址的获取方法、设备和系统
CN102857585A (zh) * 2011-06-30 2013-01-02 中兴通讯股份有限公司 Bbf网络地址分配和策略执行的方法及系统
EP3069708B1 (en) * 2011-10-06 2018-05-09 Combocap, Inc. Capsule
US9210195B2 (en) * 2011-10-20 2015-12-08 Huawei Technologies Co., Ltd. Method, apparatus, and system for processing service data
CN103209401B (zh) * 2012-01-12 2018-07-24 中兴通讯股份有限公司 一种融合网络中策略控制方法及系统
EP2648364B1 (en) 2012-03-07 2018-06-06 Accenture Global Services Limited Communication collaboration
WO2013163634A1 (en) * 2012-04-27 2013-10-31 Interdigital Patent Holdings, Inc. Systems and methods for personalizing and/or tailoring a service interface
US20150326430A1 (en) * 2012-07-10 2015-11-12 Hewlett-Packard Development Company, L.P. Home Network Information
US9344452B2 (en) 2012-07-19 2016-05-17 Sprint Communications Company L.P. User control over WiFi network access
CN103582159B (zh) * 2012-07-20 2018-11-30 南京中兴新软件有限责任公司 一种固定移动网络融合场景下的多连接建立方法及系统
WO2014029443A1 (en) * 2012-08-23 2014-02-27 Telefonaktiebolaget L M Ericsson (Publ) Access control for a wireless local area network
US9374236B2 (en) * 2013-04-09 2016-06-21 Alcatel Lucent Network device with tunnel establishment control based on site-type attribute received from other network device
CN106464708B (zh) * 2014-06-25 2020-01-31 柏思科技有限公司 针对符合条件的包通过隧道传输和接收数据的方法和系统
KR102157185B1 (ko) * 2014-07-04 2020-09-18 삼성전자주식회사 무선 통신 시스템에서 접속 계층을 통해 서비스 연결을 제공하는 장치 및 방법
US10833880B2 (en) 2014-08-07 2020-11-10 Nokia Technologies Oy Controlled switching of multicast traffic between selective and inclusive routes based on number of multicast receivers
US9473315B2 (en) 2014-08-07 2016-10-18 Alcatel Lucent Network device configured to track multicast receivers
US9826370B2 (en) 2014-10-10 2017-11-21 T-Mobile Usa, Inc. Location identifiers in mobile messaging
US10594548B2 (en) 2014-10-27 2020-03-17 Hewlett Packard Enterprise Development Lp Home network information
FR3041846A1 (fr) * 2015-09-29 2017-03-31 Orange Technique de gestion d'une adresse dans un reseau local
US10517126B2 (en) 2015-10-19 2019-12-24 Time Warner Cable Enterprises Llc Communication management and wireless roaming support
US10432500B2 (en) * 2015-11-09 2019-10-01 Atmel Corporation Debugger for wireless sensor networks
KR102088717B1 (ko) 2016-04-08 2020-03-13 한국전자통신연구원 비접속계층 기반 액세스 방법 및 이를 지원하는 단말
US10419994B2 (en) 2016-04-08 2019-09-17 Electronics And Telecommunications Research Institute Non-access stratum based access method and terminal supporting the same
JP6414139B2 (ja) * 2016-05-24 2018-10-31 トヨタ自動車株式会社 電池パック
US10694364B2 (en) * 2017-03-24 2020-06-23 Apple Inc. Providing a local address while roaming
US11102169B2 (en) 2019-06-06 2021-08-24 Cisco Technology, Inc. In-data-plane network policy enforcement using IP addresses
CN111224855B (zh) * 2019-12-16 2021-11-30 武汉思为同飞网络技术股份有限公司 基于Linux的虚拟网卡实现方法、装置、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0955762A (ja) * 1995-08-14 1997-02-25 Nippon Telegr & Teleph Corp <Ntt> 端末装置接続許可方法及びシステム
JPH1032610A (ja) * 1996-07-12 1998-02-03 Nec Corp 移動データ通信における仮想私設網の構成方法
JP2002094546A (ja) * 2000-09-19 2002-03-29 Kddi Corp モバイルｉｐにおけるアドレス変換方法
WO2002077820A1 (en) 2001-03-26 2002-10-03 Bluesocket, Inc. Methods and systems for enabling seamless roaming of mobile devices among wireless networks
WO2002087160A2 (de) 2001-04-24 2002-10-31 Siemens Aktiengesellschaft Heterogenes mobilfunksystem

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5751967A (en) * 1994-07-25 1998-05-12 Bay Networks Group, Inc. Method and apparatus for automatically configuring a network device to support a virtual network
US5862481A (en) * 1996-04-08 1999-01-19 Northern Telecom Limited Inter-technology roaming proxy
US6061650A (en) 1996-09-10 2000-05-09 Nortel Networks Corporation Method and apparatus for transparently providing mobile network functionality
US6092200A (en) * 1997-08-01 2000-07-18 Novell, Inc. Method and apparatus for providing a virtual private network
US6079020A (en) * 1998-01-27 2000-06-20 Vpnet Technologies, Inc. Method and apparatus for managing a virtual private network
JP3641128B2 (ja) 1998-02-20 2005-04-20 株式会社東芝 移動計算機装置、移動計算機管理装置、移動計算機管理方法及び通信制御方法
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network
FR2790177B1 (fr) * 1999-02-22 2001-05-18 Gemplus Card Int Authentification dans un reseau de radiotelephonie
US6765591B2 (en) * 1999-04-02 2004-07-20 Nortel Networks Limited Managing a virtual private network
AU4603100A (en) * 1999-05-03 2000-11-17 Nokia Corporation Sim based authentication mechanism for dhcrv4/v6 messages
US7882247B2 (en) * 1999-06-11 2011-02-01 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US6332077B1 (en) * 1999-07-29 2001-12-18 National Datacom Corporation Intelligent roaming in AGV application
US6480717B1 (en) * 1999-09-28 2002-11-12 Motorola, Inc. Tunneling of non-GSM signaling messages in a GSM based network to enable both non-GSM circuit service and GSM packet service to the mobile station
US6522880B1 (en) * 2000-02-28 2003-02-18 3Com Corporation Method and apparatus for handoff of a connection between network devices
FI20000574A (fi) * 2000-03-13 2001-09-14 Nokia Mobile Phones Ltd Kuorman tasaus IP-liikkuvuutta tukevassa tietoliikennejärjestelmässä
JP3447687B2 (ja) * 2000-10-13 2003-09-16 日本電気株式会社 無線ネットワークシステム及びネットワークアドレス割当方法
US7111065B2 (en) * 2000-11-29 2006-09-19 Efficient Networks, Inc. Method and apparatus for managing tunneled communications in an enterprise network
US7039027B2 (en) * 2000-12-28 2006-05-02 Symbol Technologies, Inc. Automatic and seamless vertical roaming between wireless local area network (WLAN) and wireless wide area network (WWAN) while maintaining an active voice or streaming data connection: systems, methods and program products
FI110977B (fi) * 2001-02-09 2003-04-30 Nokia Oyj Mekanismi palvelujen mainostamista ja käyttäjän auktorisointia varten
US6978128B1 (en) * 2001-05-04 2005-12-20 Utstarcom, Inc. System and method to allow simple IP mobile nodes to operate seamlessly in a mobile IP network with true roaming capabilities
KR100389819B1 (ko) * 2001-07-09 2003-07-02 삼성전자주식회사 부호분할다중접속 이동통신시스템에서 패킷 데이터 전송방법
US7301922B1 (en) * 2001-09-17 2007-11-27 Cisco Technology, Inc. Real time handoff in a wireless packet data network
US7617317B2 (en) * 2001-12-03 2009-11-10 Sprint Spectrum L.P. Method and system for allowing multiple service providers to serve users via a common access network
KR20040074135A (ko) * 2002-01-29 2004-08-21 코닌클리즈케 필립스 일렉트로닉스 엔.브이. 통신 시스템, 통신 수행 방법, 소프트웨어 제품,클라이언트 장치 및 서버
US7634249B2 (en) * 2002-06-07 2009-12-15 Siemens Aktiengesellschaft Method and device for authenticating a subscriber for utilizing services in a wireless LAN while using an IP multimedia subsystem of a mobile radio network
US7155526B2 (en) * 2002-06-19 2006-12-26 Azaire Networks, Inc. Method and system for transparently and securely interconnecting a WLAN radio access network into a GPRS/GSM core network
US20040181692A1 (en) * 2003-01-13 2004-09-16 Johanna Wild Method and apparatus for providing network service information to a mobile station by a wireless local area network
JP4270888B2 (ja) 2003-01-14 2009-06-03 パナソニック株式会社 Ｗｌａｎ相互接続におけるサービス及びアドレス管理方法
KR20060031813A (ko) * 2003-06-18 2006-04-13 텔레폰악티에볼라겟엘엠에릭슨(펍) Ｃｄｍａ 시스템에서 이동ｉｐ 버전 6 서비스 지원하기위한 방법, 시스템 및 장치
US7283822B2 (en) * 2003-10-17 2007-10-16 Kineto Wireless, Inc. Service access control interface for an unlicensed wireless communication system
US7272397B2 (en) * 2003-10-17 2007-09-18 Kineto Wireless, Inc. Service access control interface for an unlicensed wireless communication system
US8238326B2 (en) * 2004-11-18 2012-08-07 Ruckus Wireless, Inc. Maintaining consistent network connections while moving through wireless networks
US8031672B2 (en) * 2004-12-28 2011-10-04 Samsung Electronics Co., Ltd System and method for providing secure mobility and internet protocol security related services to a mobile node roaming in a foreign network
US7373661B2 (en) * 2005-02-14 2008-05-13 Ethome, Inc. Systems and methods for automatically configuring and managing network devices and virtual private networks
US8369292B2 (en) * 2006-06-30 2013-02-05 Industrial Technology Research Institute Method and apparatus for mobility management in communication networks
KR100907507B1 (ko) * 2007-03-05 2009-07-14 삼성전자주식회사 무선 랜 단말의 ｂｗａ 네트워크 연동시 사용자 인증 방법및 그 시스템
US8023492B2 (en) * 2007-07-18 2011-09-20 Marvell World Trade Ltd. System and method for allocating an anchoring point for a mobile terminal
WO2010064801A2 (en) * 2008-12-04 2010-06-10 Electronics And Telecommunications Research Institute Tunneling-based mobility support equipment and method
EP2405678A1 (en) * 2010-03-30 2012-01-11 British Telecommunications public limited company System and method for roaming WLAN authentication

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0955762A (ja) * 1995-08-14 1997-02-25 Nippon Telegr & Teleph Corp <Ntt> 端末装置接続許可方法及びシステム
JPH1032610A (ja) * 1996-07-12 1998-02-03 Nec Corp 移動データ通信における仮想私設網の構成方法
JP2002094546A (ja) * 2000-09-19 2002-03-29 Kddi Corp モバイルｉｐにおけるアドレス変換方法
WO2002077820A1 (en) 2001-03-26 2002-10-03 Bluesocket, Inc. Methods and systems for enabling seamless roaming of mobile devices among wireless networks
WO2002087160A2 (de) 2001-04-24 2002-10-31 Siemens Aktiengesellschaft Heterogenes mobilfunksystem

Non-Patent Citations (1)

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

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1633083A1 (en) * 2003-06-06 2006-03-08 Huawei Technologies Co., Ltd. A method of user access authorization in the wlan
EP1633083A4 (en) * 2003-06-06 2006-09-13 Huawei Tech Co Ltd METHOD FOR USER ACCESS AUTHORIZATION IN WLAN
US7519036B2 (en) 2003-06-06 2009-04-14 Huawei Technologies Co., Ltd. Method of user access authorization in wireless local area network
US8077688B2 (en) 2003-06-06 2011-12-13 Huawei Technologies Co., Ltd. Method of user access authorization in wireless local area network
US8116782B2 (en) 2007-02-28 2012-02-14 Hitachi, Ltd. Communication quality control system

Also Published As

Publication number Publication date
US20150249917A1 (en) 2015-09-03
CA2512959A1 (en) 2004-09-10
US20170134936A1 (en) 2017-05-11
KR20050092405A (ko) 2005-09-21
US20060209768A1 (en) 2006-09-21
KR20090061663A (ko) 2009-06-16
US9986426B2 (en) 2018-05-29
EP2512067B1 (en) 2017-06-14
US9055563B2 (en) 2015-06-09
JP4270888B2 (ja) 2009-06-03
CN101299759B (zh) 2013-01-02
US20180249326A1 (en) 2018-08-30
KR100967749B1 (ko) 2010-07-05
US8374580B2 (en) 2013-02-12
US20120082111A1 (en) 2012-04-05
CN100405776C (zh) 2008-07-23
US10511961B2 (en) 2019-12-17
EP1585270A1 (en) 2005-10-12
EP2512067A1 (en) 2012-10-17
CN1762129A (zh) 2006-04-19
KR100999761B1 (ko) 2010-12-08
US8081971B2 (en) 2011-12-20
CN101299759A (zh) 2008-11-05
US7610038B2 (en) 2009-10-27
CA2512959C (en) 2013-03-26
JP2004266310A (ja) 2004-09-24
US20100002668A1 (en) 2010-01-07
US9560521B2 (en) 2017-01-31
EP1585270A4 (en) 2011-12-28
US20130121292A1 (en) 2013-05-16

Similar Documents

Publication Publication Date Title
US10511961B2 (en) Service in WLAN inter-working, address management system, and method
US9112909B2 (en) User and device authentication in broadband networks
JP3778129B2 (ja) 無線ネットワークおよび無線ネットワークにおける認証方法
EP2589258B1 (en) Method and apparatus for a mobile node to connect to different access routers while maintaining a consistent network address
FI109950B (fi) Osoitteen saanti
JP5502905B2 (ja) モバイル・ネットワークにおけるセキュア・ネットワークベースのルート最適化のための方法
JP5987122B2 (ja) デバイス固有のトラフィックフローステアリングのためのネットワークアドレス変換されたデバイスの特定
US20120213216A1 (en) Telecommunications apparatus and method
JP2007519379A (ja) Ｉｐアクセスネットワークを用いたマルチホーミング及びサービスネットワーク選択
JP2008535301A (ja) パケット無線ネットワーク及び通信方法
Li et al. Public access mobility LAN: extending the wireless Internet into the LAN environment
JP4802238B2 (ja) ローカルネットワーク相互接続における移動端末に対してネットワークに基づくトンネルを設定する方法
Vieira of Deliverable: Access Technologies in LONG Project
Mort et al. SatSix and Recent Standardisation Results in ETSI Broadband Satellite Multimedia (BSM) Networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

Ref document number: 2004702063

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2512959

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1020057012955

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 3234/DELNP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 20048069567

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020057012955

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2004702063

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10541447

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10541447

Country of ref document: US