Address management method, address management system, mobile terminal and home domain server

ADDRESS MANAGEMENT METHOD, ADDRESS MANAGEMENT SYSTEM, MOBILE TERMINAL AND HOME DOMAIN SERVER}

<p>The present invention relates to the field of wireless data communication. In particular, the present invention relates to address management for mobile users visiting from different networks, in a wireless LAN (WLAN) environment, wherein the WLAN is, for example, in a different administrative domain, and a 3G network using a different radio technology. It can be used when performing inter-networking with a public wireless network such as a WLAN or WLAN. In addition, the present invention can be used as a mobile terminal in addition to a WLAN and an inter-worked network for address assignment, configuration, tunneling setup, etc. become accessible.</p>

<p>In WLAN inter-working, the terminal needs to be addressable so that the terminal can access all services subscribed to. If the service is transmitted over IP, the terminal will be associated with some IP address. In the mobile world, the access point of the terminal changes frequently, so that it can sufficiently occur that the terminal switches several domains between any active service sessions. In order to satisfy this terminal mobility requirement, the address management mechanism is required to configure and update the address of the terminal whenever the terminal changes the access point.</p><p>Mobile IP is a standardized technology disclosed by the Internet Technology Review Committee (IETF) (Non-Patent Document 1) (Non-Patent Document 2), and provides a solution for address management and traffic routing for mobile terminals. With this technology, when roaming within multiple IP networks, the user is reachable while using the same address. Because mobility is managed at the IP level, mobile IP is not bound by the underlying link layer technology, and the same protocol stack can be applied to terminals in a 3G cellular network or a wireless LAN (eg, an 802.11 network). becomes In the convergence of access technologies such as, for example, the interconnection of WLAN and 3G cellular networks, a solution of this kind of harmonized level is particularly useful. In Mobile IP, address management is performed by IP connection, and address management becomes impossible when IP connection is not available. In addition, in Mobile IP, it is necessary for the terminal to further go to the home address and to know the home agent. This requirement may not be satisfied in the operation process of interconnection, for example, when the terminal starts operation in a foreign WLAN for the first time.</p><p>Also, in the Mobile IPv6 draft, a method for setting a home address of a mobile node is introduced (Non-Patent Document 2). The terminal first generates a care of address using, for example, DHCPv6 (Non-Patent Document 3), and communicates with a home network that uses this address to set a final home address. . However, if the care-of address obtained from the WLAN is used, the home network of the mobile node is not necessarily made locatable, thus rendering it inoperable in the WLAN interconnection. In addition, the configuration process in which a plurality of times of negotiation is performed is time-consuming and does not meet the user's expectations.</p><p>In addition, by application of Diameter Mobile IPv6 (Non-Patent Document 4), a solution for address management of Mobile IPv6 is proposed based on the configuration of AAA. In this solution, it is used that the AAA server and the clients of the moving destination and the home network perform address update and agent discovery. In that mechanism, the mobile node is required to have a local IP connection for exchanging messages, e.g. it can listen to Router Advertisement messages, but the local policy of the foreign domain It cannot be said that it is necessarily possible by Also, this mechanism is provided only in a situation where the address belongs to the home domain of the mobile terminal. In WLAN interconnection, the terminal uses an address from another domain that depends on the service the terminal is accessing, and since this address does not have the service request information of the terminal, this mechanism cannot support LWAN interconnection. can't This mechanism is designed for the mobile IPv6 environment, so it cannot be operated in a terminal without a mobile IP stack.</p><p>In addition, as a solution by 3GPP, GTP (Non-Patent Document 5) for managing terminal addressing and tunneling is provided. GTP has two parts: GTP-C for control and GTP-U for traffic of user data. GTP operates on UDP and encapsulates user data in UDP packets. This GTP is designed for a GPRS (Non-Patent Document 6) network, and is highly dependent on the characteristics of a GPRS network such as, for example, GGSN and SGSN node, and is applied to a simple radio access network (eg, WLAN). creep is difficult</p><p>Non-patent document 1 "IP mobility support for IPv4"</p><p>http://www.ietf.org/rfc/rfc3344.txt</p><p>Non-patent document 2 Mobility support in IPv6</p><p>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt</p><p>Non-patent document 3 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"</p><p>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt</p><p>Non-Patent Document 4 Diameter Mobile IPv6 Application</p><p>http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt</p><p>Non-Patent Document 5 GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface (Release 5) 3GPP TS 29.060 V5.3.0 (2002-09)</p><p>ftp://ftp.3gpp.org/Specs/archive/29_series/</p><p>Non-Patent Document 6 "General Packet Radio Service (GPRS); service description; Stage 2 (Release 5) 3GPP TS 23.060 V5.2.0 (2002-06)</p><p>ftp://ftp.3gpp.org/Specs/archive/23_series</p><p>Non-Patent Document 7 "IP Multimedia Subsystem (IMS); Stage 2 (Release 5)" 3GPP TS 23.228 V5.6.0 (2002-09)</p><p>ftp://ftp.3gpp.org/Specs/archive/23_series/</p><p>Non-patent document 8 "Diameter Base Protocol"</p><p>http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt</p><p>Non-patent document 9 "PPP Extensible Authentication Protocol (EAP)"</p><p>http://www.ietf.org/rfc/rfc2284.txt</p><p>Non-Patent Document 10 3GPP project http://www.3gpp.org</p><p>Non-Patent Document 11 3GPP2 project http://www.3gpp2.org</p><p>Non-patent document 12 The Network Access Identifier</p><p>http://www.ietf.org/rfc/rfc2486.txt</p><p>Non-Patent Document 13 Numbering, addressing and identification (Release 5) 3GPP TS 23.003 V5.3.0 (2002-06)</p><p>ftp://ftp.3gpp.org/Sepcs/archive/23_series/</p><p>Non-Patent Document 14 "Port-Based Network Access Control" IEEE Std 802.1X-2001 http://standards.ieee.org/getieee802/</p><p>Non-Patent Document 15 Diameter Extensible Authentication Protocol (EAP) Application</p><p>http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt</p><p>Non-Patent Document 16 "Diameter NASREQ Application"</p><p>http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt</p><p>Non-Patent Document 17 IPv6 Stateless Address Autoconfiguration</p><p>http://www.ietf.org.rfc/rfc2462.txt</p>

<solutionproblem><p>WLANs and interconnection networks typically reside in different management domains. This means that the address space is managed separately. Therefore, when the mobile terminal moves to a WLAN in a domain different from its home network, some address configuration must be performed to ensure continuous service delivery to the terminal. This address configuration also includes IP address assignment, address registration, tunneling setting, and the like, for example.</p><p>In order to allow any service to be delivered to a terminal via WLAN, address limitation is performed. For example, in WLAN, in order to access an IMS (Non-Patent Document 7) service in a 3G network, a terminal needs to have an address belonging to a network providing IMS, and as a result, a movement that performs parallel access to other services The terminal is required to be assigned a plurality of IP addresses.</p><p>In WLAN, before authentication and its permission are granted, the terminal is not permitted to use any resource, for example, sending and receiving normal data packets. For example, in a typical mechanism suggested in MIPv6, address configuration is performed only after successful authorization processing, but such an approach takes time and cannot satisfy the requirements for some services. In order to perform the address construction before this permission process, information related to the address construction needs to be incorporated into the access control message. Further, address management is usually based on the user's subscription information, and needs to be managed by the home network of the mobile terminal. However, in any external service, an address needs to be assigned in a domain other than the home network. In this case, there is a need for a mechanism for the home network to perform address assignment and exchange of other information possessed by the domain.</p><p>In addition, when the terminal changes the address, end-to-end QoS related to the terminal is affected. For example, if the address is changed, it becomes impossible to accurately classify the flow by the transmission destination address or the traffic filter based on the transmission destination address information. For a WLAN implementing a firewall or other traffic control function, a new address of the terminal needs to appear more, otherwise traffic is interrupted or stopped.</p></solutionproblem><meansproblemsolution><p>The address management method of the present invention is an address management method in which a mobile terminal accesses a service provided in a home domain network of the mobile terminal from a WLAN access network or a service provided in a service provider network via the home domain network, An access step in which the mobile terminal accesses the WLAN access network, and a tunnel establishment request message including a service request identifier for accessing a service requested by the mobile terminal and an identifier of the mobile terminal from the WLAN access network a transmitting step of transmitting to a home domain server arranged in a domain network, wherein the home domain server receives the tunnel establishment request message, and provides the service requested by the mobile terminal based on the service request identifier and the identifier of the mobile terminal. It has an allocation step of allocating an address for access.</p><p>In addition, the address management system of the present invention includes a mobile terminal and a home domain server, wherein the mobile terminal is provided from a WLAN access network in a home domain network of the mobile terminal or a service provider via the home domain network. An address management system for accessing a service provided by a network, wherein the mobile terminal includes a connection unit for accessing the WLAN access network, a service request identifier for accessing the requested service, and an identifier of the mobile terminal. a transmitter for transmitting a message from the WLAN access network to the home domain server disposed in the home domain network, wherein the home domain server receives the tunnel establishment request message, the service request identifier and the identifier of the mobile terminal and an allocator for allocating an address for accessing a service requested by the mobile terminal based on the .</p><p>In addition, the mobile terminal of the present invention is a mobile terminal that accesses a service provided in a home domain network of the mobile terminal from a WLAN access network or a service provided in a service provider network via the home domain network of the mobile terminal, A connection unit for accessing the WLAN access network, and a tunnel establishment request message including a service request identifier for accessing a requested service and an identifier of the mobile terminal from the WLAN access network to a home domain server disposed in the home domain network It has a transmitting unit that transmits.</p><p>In addition, the home domain server of the present invention is the home domain of the mobile terminal accessing the service provided in the home domain network of the mobile terminal from the WLAN access network or the service provided in the service provider network via the home domain network. A home domain server disposed in a network, receiving a tunnel establishment request message including a service request identifier for accessing a service requested by the mobile terminal and an identifier of the mobile terminal, from the mobile terminal, the service request identifier and the and an allocator for allocating an address for accessing a service requested by the mobile terminal based on the identifier of the mobile terminal.</p></meansproblemsolution>

<p>The present invention is that WLAN is used to inter-work with other networks. Other WLANs or public cellular networks are possible as interconnected networks, and the present invention can be easily applied in any case. Further, the present invention is used for the purpose of providing services related to address management and address transition (that is, mobility control).</p><p>In case of applying the scheme proposed here, there is no need to implement a special interface or protocol. This mechanism reuses existing access control mechanisms and extends some of its properties to support the required functionality. In address assignment, the modification is incorporated into the service authorization procedure. Since the authorization procedure is encrypted and protected by the trust obtained from authentication, the address information is also protected with the same security level and displayed as a part of the authorization information so that it can be transmitted in the same way as the normal authorization information. For example, it can be included in Diameter (Non-Patent Document 8) as permission specific to AVP, or can be included as an attribute of EAP (Non-Patent Document 9) when permission by EAP method is available.</p><p>When the terminal enters the WLAN, authentication and authorization are performed before use of the service is permitted. In the authorization procedure, the terminal requests a service to be accessed, and this information is handed over to the terminal's home network through the WLAN. The terminal's home network determines whether or not to authorize the service based on the user's subscriber profile. Further, according to the requested service, the home network of the terminal determines the address used for the service. For example, for an IMS service, an address needs to be allocated in the IMS address space, while for a local WLAN service a locally obtained address is sufficient. In addition, confirmation of tunneling information related to address management is further performed.</p><p>The address information is included in the permission information and transmitted together with the permission success message. A part of this information is transmitted to the WLAN, and a part is transmitted to the terminal as in a normal authorization procedure. For example, in order for the terminal to be able to do the address configuration of the terminal itself, the address needs to be sent to the terminal. Also, if network tunneling is required, tunneling information is used by the WLAN.</p><p>In addition, when it is necessary to change the address, the re-licensing procedure can be used to perform rapid update without performing the detailed procedure for service permission.</p><p>Also, when the terminal starts access to the service, policy control is started. The address information is made available by a policy server of the terminal's home network, and thereafter, the policy server can make policy decisions based on the address information. In addition, at the time of address change, a notification is made to the policy server to update the corresponding policy, and as a result, QoS and service provision are guaranteed.</p><p>To support an understanding of the invention, the following definitions are used.</p><p>"WLAN" refers to a wireless local area network, and includes any number of devices for providing LAN services to mobile terminals through wireless technology.</p><p>"3G network" refers to a third-generation public access network, and is, for example, a system defined by 3GPP (Non-Patent Document 10) or 3GPP2 (Non-Patent Document 11).</p><p>A "mobile terminal" refers to a device used for access to services provided by WLANs and other networks by radio technology.</p><p>"Home network" refers to a network in which service subscription information of a mobile terminal (MT) is stored, and in an interconnection scenario, a network to which the MT initially subscribes, or a destination to which full access to the subscription information of the MT is permitted. It is a network.</p><p>The "service provider network" refers to a network in which the service requested by the MT is provided, and for example, any network such as a home network, WLAN, or external network is possible.</p><p>A "network element" refers to an arbitrary device functioning in a network capable of executing information processing.</p><p>"Policy Server" refers to a network element that executes a policy control function of a network domain. The policy control function includes, for example, local resource allocation, packet filter update, routing update, and the like.</p><p>"Air Interface" refers to any radio access technology for a mobile terminal to access WLAN.</p><p>A "stream" is a set of packets transmitted within a network having certain attributes in common.</p><p>"Traffic" is a set of streams transmitted within a network.</p><p>A "flow" refers to a data path and a network resource required for a data path used to transmit a stream.</p><p>"QoS" refers to the term of quality of service of a data stream or traffic.</p><p>"Message" refers to information exchanged between network elements for the purpose of controlling interconnection.</p><p>"Operation Sequence" refers to a series of message exchanges between arbitrary network elements for interconnection control.</p><p>"Upper layer" refers to all entities that exist on the current entity and process packets taken over from the current entity.</p><p>The "client-based tunnel" refers to a tunneling mechanism in which one of the endpoints of the tunnel is a mobile terminal.</p><p>The "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.</p><p>In the following description, specific numbers, times, structures, names of protocols, and other parameters are used in the description for fully understanding the present invention. It is apparent to those skilled in the art that the present invention can be practiced without these specific descriptions. In addition, well-known components and modules are shown in block diagram form in order not to unnecessarily obscure the present invention.</p><p>Due to the characteristic that the terminal has a high degree of mobility, mobility control is one of the most prominent problems in WLAN interconnection. When the terminal moves, the terminal is requested to use a non-local (local) address for the access point. For example, for a 3G terminal entering WLAN, a 3G domain address is required to access the home network service (eg, IMS service). 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 this address is associated with the 3G cellular interface of the terminal. . In addition, when the terminal enters the WLAN domain, it is desired to communicate using the WLAN interface because high throughput can be realized. For example, a PDA having dual interfaces (GPRS and IEEE802.11) is desired to use the GPRS interface on the road and the IEEE802.11 interface in a hotspot. When the terminal accesses the 3G service using the WLAN interface, the terminal needs to continue to use the same address obtained from the 3G interface. Otherwise, the terminal faces service interruption and has to re-initialize the session, which is not desirable for the user. Also, since the address being used is not local to the WLAN, a tunnel must be established from the terminal to the service provider network.</p><p>1, an embodiment of the present invention for address assignment and tunnel set-up is shown. Also, to avoid confusion, only network entities participating in the signaling are shown.</p><p>The mobile terminal 101 is an entity that requests a certain service in the network. In practice, it is possible to have several entities, for example a handset connected to a laptop computer by way of a Bluetooth link, but for simplicity it is shown as one configuration in FIG. 1 . have. Within a WLAN function 1001 , an access point 105 is an entity that provides WLAN access to a mobile terminal 101 . Until the mobile terminal 101 is given permission to use the WLAN service, the access point 105 blocks all data traffic from the mobile terminal 101, but a control channel that only permits certain data packets does not allow access control signaling. Open to act. The mobile terminal 101 communicates with the access point 105 via a radio link 1011 . As this link, it is possible to use any kind of radio technology, including for example IEEE802.11, Hiper LAN/2, infrared, etc., if the same access control technology is applicable, on this link, for example , it is also possible to use other technologies such as optical fibers. In addition, the WLAN management server (WLAN server) 102 exists as a separate entity in the WLAN. The WLAN server 102 is in charge of address space management and resource management of the WLAN, and is located on the gateway of the WLAN or is installed together with the access point 105 in a simple WLAN. The WLAN server 102 communicates with the access point 105 via the interface 1015 . This is for, for example, WLAN resource control and service provision, such as QoS management via an air interface. Also, in order to manage the WLAN, the server may interact with other entities of the WLAN, such as, for example, a WLAN gateway or firewall (not shown).</p><p>In the home network 1002 of the terminal, the Home Network Authorizer 103 manages service authorization and address assignment. The access point 105 and the WLAN server 102 are both, the link 1012 and the link Each communicates with the home network authenticator 103 to obtain service control information through 1014. It is also possible to physically make the link 1012 and the link 1014 identical, that is, between the same terminals using the same protocol. Even if they are encapsulated in the same packet in , they are logically separated.</p><p>The mobile terminal 101 can request any service to which it subscribes. These services may be in the home network 1002 , a separate service provider network 1003 , or the WLAN itself. If the service is provided by the home network 1002 or WLAN, the service provider network 1003 will overlap with these networks, allowing control functions to be related to both. In addition, the service provider network management server (service provider network server) 104 manages service authorization and address assignment of the service provider network 1003 . The home network authenticator 103 communicates with the service provider network server 104 via the control interface 1013 . In practice, a WLAN, home network 1002 or other network may be used as the service provider network 1003 . In addition, when the service is provided in the home network 1002, this interface becomes an internal interface, and it is not necessary to use the exact format but the same protocol as described in the embodiment to be described later.</p><p>Figure 2 shows an example of an operation sequence for WLAN interconnect address management using the above framework. Also, in this operation, it is assumed that the mobile terminal (MT) 101 has already finished the WLAN-related grant and authentication procedure 201 . That is, the mobile terminal 101 and the access point 105 are mutually authenticated, and protection by encryption for the subsequent message exchange has already been made. When 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 link 1011, and the message is sent to the home network authenticator 103. is reached This message is protected end-to-end by the key generated in the authentication procedure 201 . 3 shows an embodiment of the message MT_Request_A message 202A.</p><p>The message begins with the Message_Type field (301). This field identifies what kind of message is encapsulated, for example a request or reply. The length of this field is 1 octet, and the message type is expressed by an integer number. This saves limited resources for signaling over the air interface. In addition, it is clear to those skilled in the art that other formats of this field can also be adopted if necessary. Following the Message_Type field 301 , there is a Message_Length field 302 . This includes information about the length of the entire message including the Message_Type field 301 . Also, the next field is the Domain_Name field 303 . This field identifies the home domain of the mobile terminal 101 . In addition, it is also possible to use a Network Access Identifier (NAI) (Non-Patent Document 12), and in this case, for example, it takes the form "UserID@home.domain.3gpp.org". In order to protect the user's identification information, the UserID part before the "@" symbol uses a wildcard value such as "roamed", for example. The home domain information is used to route messages to the home network authenticator 103 of the mobile terminal 101 .</p><p>The above three fields, the Message_Type field 301 , the Message_Length field 302 and the Domain_Name field 303 , are protected by the security association between the mobile terminal 101 and the access point 105 . This security association is obtained from the authentication procedure 201 for the protection of the air interface. Thus, to achieve the purpose, it is possible for the access point 105 to access the information contained in their fields. The field following the Domain_Name field 303 is protected by the security association between the mobile terminal 101 and the home network authenticator 103 . For example, this could be the public key of the home network authenticator 103, that is, the session key derived from the authentication procedure 201, indicating the index of the key used for message protection. For this purpose, it is also possible to use the UserID part of the Domain_Name field 303 .</p><p>After the Domain_Name field 303 , there is an MT_ID field 304 . This field includes information for uniquely identifying the mobile terminal 101 in the context of the home network 1002 . This can be, for example, the IMSI of the mobile terminal 101 (Non-Patent Document 13) or a TMSI (Non-Patent Document 13) obtained in an authentication procedure. The home network authenticator 103 uses this identifier to retrieve the user's subscription information. It will be apparent to those skilled in the art that it is possible to use other formats for this field as long as the home network authenticator 103 can map it to the actual user identification information.</p><p>The next field is the Service_Request field (305). This field is used by the mobile terminal 101 to indicate the service it wishes to access to the home network authenticator 103 . Since the message is between the mobile terminal 101 and its home network authenticator 103, it is specific to a particular operator and network. For example, in a 3GPP network, this may be an APN (Non-Patent Document 13) for identifying a GGSN to use and a special service to access. It is apparent to those skilled in the art that other formats may be used when the home network 1002 is of a different type. It is also possible to add other service request information such as bandwidth request. Possible values for the field include "2M.bandwidth.request.IMS.foo.bar.operator-name.operator-group.gprs". The latter part of "request" is a standard APN for identifying a service, and the first part of "request" is a specific service request. The actual request attribute depends on the service, and can also be defined by the operator. The mobile terminal 101 may obtain information about the format from a SIM or a USIM card.</p><p>In addition, the Session-ID field 306 provides session control information. This is used by the mobile terminal 101 to identify that the request for this service is a session related to the home network authenticator 103 . The identifier of the session must be locally unique within the mobile terminal 101, and the mobile terminal 101 must maintain a local record of all service sessions. When a new service session is started, a new entry with a new session identifier is always created, and when the session ends, the entry is deleted, and the identifier is released and reusable. In this embodiment, the field is 2 octets, and the identifier is a hexadecimal value. In addition, it is clear 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 a service session in the home network authenticator 103 .</p><p>Also, the Address_Request field 307 contains information regarding a request for granting address assignment from the mobile terminal 101 . In this embodiment, as shown in FIG. 4, a complex structure is used. The first part of this structure is the Address_Type field (401). This identifies what types of addresses are supported for the mobile terminal 101 . The size of this field is 1 octet, and the possible values are as follows.</p><p>No_IP::=OxOO;</p><p>Single_Stack_IPv4::=0x01;</p><p>Single_Stack_IPv6_FullAddress::=0x02;</p><p>Single_Stack_IPv6_Prefix::=0x03;</p><p>Dual_Stack_IPv4_Preferred::0x04;</p><p>Dual_Stack_IPv6_Preferred_FullAddress::=0x05;</p><p>Dual_Stack_IPv6_Preferred_Prefix::=0x06</p><p>It will be apparent to those skilled in the art that more types are supported and other numbers may be used. Also, the second part of this structure is the Suggestion_Length field 402 . This field indicates the length of the Address_Suggestions field 403 which is the next field. The Address_Suggestions field 403 lists the addresses to which the mobile terminal 101 wishes to be assigned. For example, if an ongoing session is using an address, it is important that the same address is assigned so that the session is not interrupted. For example, the Address_Suggestions field 403 is a list of addresses. Each entry in the list begins with a type field of one octet indicating the type of address, for example IPv4 or IPv6, followed by the actual address. In the home network authenticator 103 that does not support the feature of address presentation by the terminal, the Suggestion_Length field 402 and the Address_Suggestions field 403 are implicitly ignored.</p><p>In addition, the Tunnel_Request field 308 exists after the Address_Request field 307. This field is used by the mobile terminal 101 to indicate what 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 can be a list with each entry occupying 2 octets. The first octet of each entry contains the identifier of the tunnel type supported by the mobile terminal 101, and the following octet values are possible.</p><p>network tunnel -- general::=0x01;</p><p>Network Tunnel -- Mobile IPv4::=0x02;</p><p>Client Tunnel -- General::=0x04</p><p>Client Tunnel -- Mobile IPv4::=0x05;</p><p>Client Tunnel -- Mobile IPv6::=0x06;</p><p>No tunnel::=0x08</p><p>In this field, it is clear to those skilled in the art that other tunnel types can be defined and used. Also, the second octet of each entry indicates the direction of the tunnel. Possible values for this octet are:</p><p>Tunnel -- At the terminal::=0x01;</p><p>Tunnel -- to terminal::=0x02;</p><p>tunnel -- bidirectional::=0x03;</p><p>The first entry in the list indicates the preferred type of mobile terminal 101 .</p><p>Also, the next field in the MT_Request_A message 202A is the WLAN_ID field 309 . It contains information identifying the WLAN to the home network authenticator 103 , so that the home network authenticator 103 can make location-based decisions or provide location-based services to the mobile terminal 101 . It becomes possible to provide or The WLAN_ID can be acquired from information broadcast from the access point 105, such as an authentication procedure or, for example, an SSID in an IEEE802 network. In addition, the local identifier of the mobile terminal 101 is also included. This is for the access point 105 to identify the terminal.</p><p>In addition, the last field is Security_Field (310). This field contains information to protect the message. The exact algorithm used for this field is negotiated between the mobile terminal 101 and its home network authenticator 103 . In addition, this may be determined by the user's subscription time, or may be stored in the SIM or USIM card of the terminal. In addition, it can be implemented as a software module, and when necessary, it is possible to always download it.</p><p>In addition, the fields in the MT_Request_A message 202A do not have to follow the exact sequence as described above, for example, fields 304 to 309 are arranged in any order as long as the field identifier is actually placed first. can do.</p><p>In practice, any suitable mechanism may be used to send messages over link 1011. For example, in the IEEE802.11 network, it can be realized as an EAP message using EAPOL defined by IEEE802.1x (Non-Patent Document 14).</p><p>When the access point 105 receives this message, it fetches the home domain information from the Domain_Name field 303 and uses the domain information to query the DNS, for example, to the home network authenticator 103 . address can be obtained. The access point 105 sends a message to the corresponding home network authenticator 103 according to this information. For example, if the WLAN has a central AAA server, the access point 105 sends the message directly to the AAA server. Then, the AAA server of the WLAN interprets the domain information and transmits a message to the real home network authenticator 103 . In addition, it is premised on the existence of a secure link between the access point 105 and the home network authenticator 103, which is made possible by the setting in the authentication procedure 201 or is related to security resulting from the process. This is made possible by dynamically setting grants.</p><p>Also, the access point 105 does not need to participate in message processing, and thus does not need to go through the entire stack to interpret the message. It simply needs to read the message type and do the re-encapsulation and transmission, which appears as the MT_Request_B message 202B step. As a protocol used for transmission, any suitable AAA protocol (for example, EAP application for Diameter (Non-Patent Document 15) or NASREQ application for Diameter (Non-Patent Document 16)) is possible do. Those protocols are already available at the access point 105 for authentication purposes. Accordingly, the message MT_Request_A message 202A is essentially sent end-to-end from the mobile terminal 101 to the home network authenticator 103, similar to the end-to-end authentication procedure 201 .</p><p>5 shows an embodiment of the state machine of the home network authenticator 103 . The home network authenticator 103 starts in an initial state 501 and moves to an idle state 502 by performing an initialization () process in a transition (/intiate()) 5001 . The initialization () process includes all steps necessary to establish a connection with another backend server, security association, and the like. In practice, it will be apparent to those skilled in the art that other processes may be involved depending on the configuration.</p><p>When the home network authenticator 103 receives the MT_Request_B message 202B transmitted from the access point 105 in the transition 5002 , it transitions to the message decryption state 503 . Fig. 6 shows an embodiment of the message decryption state 503. In the message decrypted state 503, the home network authenticator 103 decrypts the field in the MT_Request_B message 202B using the key identified by the Domain_Name field 303 in step 6001. If it is detected in step 6002 that the message has been corrupted or has been modified using the Security_Field 310, the home network authenticator 103 sets the flag of the invalid message in step 6013 and the state machine at transition 5004 A transition to the service rejection state 504 is made.</p><p>In the MT_Request_B message 202B, the home network authenticator 103 may obtain information about the identification information of the terminal from the MT_ID field 304 in step 6003 . Using this identification information, the home network authenticator 103 retrieves user subscription information from its database or from a backend server (eg, HSS in a 3GPP network). In addition, the home network authenticator 103 further interprets the service request information obtained in the Service_Request field 305 in step 6004. The service request may include various service-specific information to be inserted, such as bandwidth, delay, instability, etc. for example. At step 6005, a determination is made within the home network authenticator 103 as to whether to provide a service to the user using the user subscription information. If, based on the user's subscription, it is determined that the requested service should not be provided, the home network authenticator 103 sets a flag denying the service in step 6013, and the state machine goes to the service rejected state 504 at transition 5004. transition If the service is permitted, the home network authenticator 103 obtains the service terminal of the session identifier received in the Session_ID field 306 in step 6007, and searches the record. If there is a record having the same session identifier, it means that this is a handover request, and the same address should be assigned to the terminal. Accordingly, the service session is not interrupted. Also, if the record does not exist, it means that it is a new request, and in step 6008, a record entry is created and stored in the storage of the home network authenticator 103, or a back-end database such as HSS is updated, for example. do. The home network authenticator 103 further uses the service information to identify the service provider network 1003 , and a connection with the service provider network server 104 is established.</p><p>In step 6009, the home network authenticator 103 obtains from the Address_Request field 307 the address that the mobile terminal 101 wishes to use. Also, if the home network authenticator 103 does not want to support this function due to the operator's policy or something else, it can implicitly ignore this information. The mobile terminal 101 should always use the final address assigned from the home network authenticator 103 . The home network authenticator 103 determines from the requested service whether an address should be assigned locally or within the home network 1002 , or within the service provider network 1003 . For example, if a user is only authorized to use a WLAN local service, an address is assigned within the WLAN, while a user subscribing to the VPN service must be assigned using an address within that VPN.</p><p>In addition, the home network authenticator 103 retrieves the tunnel type supported by the mobile terminal 101 from the Tunnel_Request field 308 in step 6010 . This information is used to establish a tunnel for service provision. The mobile terminal 101 may list one or more tunnel types, and the first tunnel in the list may be the desired type of tunnel. The home network authenticator 103 needs to do a check with the service provider network server 104 to determine which type to use. Further, for example, additional information such as a tunnel direction may be included.</p><p>In step 6011 , the home network authenticator 103 obtains identification information of the wireless LAN with which the mobile terminal 101 is currently associated from the WLAN_ID field 309 . Using this information, the home network authenticator 103 finds the corresponding WLAN management server 102 . It is also possible, as part of the roaming agreement, to store this information in the database of the home network authenticator 103, and also to be able to retrieve this information from a back-end server (eg HSS). . After obtaining the server information, a secure link is established. This link is used for signaling a service message later.</p><p>After obtaining all the information, the home network authenticator 103 writes a Servicve_Reqeust message 203 and a WLAN_Request message 205, and when the home network authenticator 103's state machine transitions to the standby state 504, This message is sent.</p><p>7 shows an embodiment of a Service_Request message 203 . This message begins with the Home_Network_ID field 701 . This field includes information about the home network identifier of the mobile terminal 101, and may be an operator's name or a subsystem of a large network. The identifier must be globally unique, for example, the DNS name of a network such as "network.operator.3gpp.org" is a good candidate for this identifier. The presence of home network information enables the service provider network server 104 to apply network policies such as, for example, roaming agreements to service requests. In addition, the user's profile is managed by the home network 1002 . Accordingly, the user information does not have to be sent to the service provider network server 104, but it is also possible to add user priority grouping information to the message to enable better control of the service. This may be associated with a home network identifier, for example, "goldmember.network.operator.3gpp.org". The service provider network server 104 can differentiate users when providing a service using the service provider network server 104 .</p><p>Also, the next field is the MT_ID field 702 . This field contains information about the identifier of the mobile terminal 101, and is used by the home network authenticator 103 to perform service tracking. The identifier is assigned by the IMSI of the terminal or the home network authenticator 103, and may be a temporary ID unique to the service session. Also, this information needs to be consistent until the service session is terminated.</p><p>Also, following the above field, there is a Session_ID field 703 . This is the session identifier assigned by the terminal. The service provider network server 104 should keep a record of all session information currently being conducted. Thus, when the session identifier exists in the database, it means that the service request is generated by handover, and that the same address configuration must be used to avoid service interruption. For example, if the session is running (active), the service provider network server 104 must assign the same address to the mobile terminal 101 . As a result, communication with a counterpart node can be continued without signaling.</p><p>Also, the Address_Request field 704 is the same as that of the MT_Request_A message 202A. This part presents, for example, the type of address to be assigned, such as IPv6, to the service provider network server 104 . Also, similar to the Address_Request field 307 of the MT_Request_A message 202A, it provides the address requested by the mobile terminal 101 . In addition, if the service provider network server 104 does not want to support this function, this information may be ignored. Also, if it is determined by the home network authenticator 103 that an address does not need to be assigned in the service provider network 1003, this field may be omitted.</p><p>The Service_Spec field 705 is a composite field and includes information about specific requirements requested from the home network authenticator 103 based on the user's subscription information. A possible embodiment of this field (data structure 1) is shown below.</p><p>struct Service_Spec{</p><p> u_long bitrate_avg;</p><p> u_long bitrate_max;</p><p> int deliver_order;</p><p> int MTU_size;</p><p> double delay;</p><p> double jitter;</p><p> int priority;</p><p> int service_direction;</p><p> int QoS_type</p><p> struct timeval start_time;</p><p> struct timeval end_time;</p><p> };</p><p>Among these attributes, bitrate_avg and bitrate_max are the bit rate and the maximum bit rate that guarantee the requested service. In addition, the attribute of deliver_order indicates whether or not delivery is performed in order. In addition, MTU_size specifies the maximum data unit size transmitted for the service. Also, the delay and jitter fields specify some basic QoS attributes for the service. In addition, the priority attribute indicates the handling priority of data traffic for this service. In addition, the service_direction attribute indicates whether the service is unidirectional or bidirectional. Also, the QoS_type attribute indicates a QoS scheme used to provide services such as DiffServ or InterServ service with RSVP, for example. In addition, start_time and end_time indicate the start time and end time of the service. The service provider network server 104 may use this information to determine a schedule of resources for the service. In addition, it is clear to those skilled in the art that other attributes inherent to the service may be included in the structure when actually implemented.</p><p>In addition, a Tunnel_Spec field 706 exists after the Service_Spec field 705 . This field contains tunnel information and is the same as the Tunnel_Request field 308 of the MT_Request_A message 202A, but with some special information added. For example, an endpoint of a WLAN is provided for network tunnel entry, and a security key may be added for data encryption for a tunnel of a terminal.</p><p>Also, the last field of the Service_Request message 203 is a Security_Field 707 . This field is used to protect the entire message using the security association between the home network authenticator 103 and the service provider network server 104 . Again, the exact algorithm used herein depends on the actual embodiment.</p><p>Again, it will be apparent to those skilled in the art that the fields in the Service_Request message 203 need not be in the order described, in practice the home network authenticator 103 and the service provider network server 104 may use any suitable method for optimizing the signaling. It is also possible to negotiate the order.</p><p>After receiving the Service_Request message 203, the service provider network server 104 performs the service address management 204 procedure. In this procedure, the service provider network server 104 obtains the session identifier included in the Session_ID 703, and searches the database. When the session identifier of the same mobile terminal 101 exists, the service provider network server 104 copies all information in the record, such as, for example, the address of the MT and details of the service, and uses it as a reply message. It directly replies to the home network authenticator 103 .</p><p>Further, when the session identifier does not exist, the service provider network server 104 creates a new entry using the new session identifier as an index (index) of the database. The service provider network server 104 checks the Address_Request field 704 and assigns an appropriate address to the mobile terminal 101 based on the address type specified in this field.</p><p>The service provider network server 104 checks the Service_Spec field 705 from the home network authenticator 103, and if the requested service is not supported, a message indicating a failure is sent to the home network authenticator 103. is sent It is also possible to use any error code to specify the cause of the failure. In addition, if the predetermined attribute in the Service_Spec field 705 exceeds the current capability of the service provider network 1003, the service provider network server 104 establishes a new setting attribute with the home network authenticator 103. It is also possible to try to do give and take (). This is accomplished by returning the same Service_Request message 203 with the Service_Spec field 705 modified to the value suggested by the service provider network server 104 to the home network authenticator 103 .</p><p>Also, the service provider network server 104 checks the Tunnel_Sepc field 706 to find a matching tunnel type. There may be multiple matches, but the service provider network server 104 must choose the first match. As for the type of tunnel based on the network, the service provider network server 104 needs to prepare the endpoint information of the tunnel in the reply message. As for the tunnel based on the client, the service provider network server 104 prepares information specific to the tunnel type, and includes this information in the reply information. For example, as for the Mobile IPv6 type scheme, the service provider network server 104 needs to allocate a home agent to the mobile terminal 101 . It is also possible to include some security information in the reply message. In addition, directionality information (eg, unidirectional, bidirectional) may also be added to the field of the tunnel information.</p><p>The service provider network server 104 sends a reply to the home network authenticator 103 using the Service_Reply message 205 . The Service_Reply message 205 may have the same structure as the Service_Request message 203 shown in FIG. 7 .</p><p>The contents of the Home_Network_ID field 701 , the MT_ID field 702 , and the Session_ID field 703 are copied directly from the corresponding Service_Request message 203 . Also, these fields are used by the home network authenticator 103 to match the pair of request and reply messages when the signaling link is reused for a plurality of terminals.</p><p>The content of the Address_Request field 704 in the Service_Reply message 205 contains the address assigned to the mobile terminal 101, which is a list of entries for the address with the first octet indicating the length of the field in bytes. can The next part of the field is a list of addresses, with one octet indicating the type of address that accompanies the actual address. Wildcard addresses are also permitted. For example, when all address fields are satisfied with 0, a local mechanism of WLAN (eg, IPv6 automatic assignment (Non-Patent Document 17)) or DHCP is used for the mobile terminal. (101) indicates that an address is formed.</p><p>In addition, the contents of the Service_Spec field 705 in the Service_Reply message 205 include attributes agreed upon by the service provider network server 104 . If all attributes are accepted by the service provider network server 104 , they are the same as the Service_Spec field 705 in the corresponding Service_Request message 203 . On the other hand, if they are not identical, the service provider network server 104 is making a conflicting proposal to the home network authenticator 103 .</p><p>In addition, the Tunnel_Spec field 706 in the Service_Reply message 205 contains the setting of the tunnel selected by the service provider network server 104 . The exact content of this field depends on the tunnel type, and only one configuration is required if a client-based tunnel type is selected. For example, if Mobile IPv6 has been agreed upon, this field includes the address of the home agent assigned to the mobile terminal 101 and the security key for binding update authentication. Also, the address in the Address_Request field 704 is used as the home address of the mobile terminal 101 . In addition, when a tunnel type based on the network is selected, this field will include, for example, an endpoint address or a tunnel identifier, and all detailed information required for each of the tunnel types to be supported.</p><p>In parallel with the Service_Request message 203 , the home network authenticator 103 sends a WLAN_Request message 206 to the WLAN server 102 . This message is to make a contract of setting necessary for service provision in WLAN. 8 shows an embodiment of this message.</p><p>The WLAN_Request message 206, like the Service_Request message 203, includes two fields: a Home_Network_ID field 801 and an MT_ID field 802 .</p><p>The Home_Network_ID field 801 contains the identifier of the subscriber's home network, and is transferred to the WLAN server 102 when a certain network policy is applied to service provision. Also, the MT_ID field 802 is used to track the location of the mobile terminal 101 . For example, an identifier of an access point associated with a lower layer identifier (eg, MAC address) of the mobile terminal 101 may be used.</p><p>In addition, the Address_Alloc field 803 is a flag indicating whether or not it is necessary to allocate a local address of the WLAN to the mobile terminal 110, and the type of address to be used. The home network authenticator 103 determines, based on the selected tunnel scheme, whether a local address is required. In practice it is indicated whether an address assignment is required by the first octet of this field, for example using the following definition:</p><p>No_Allocation::=OxOO;</p><p>Single_Stack_IPv4::=0x01;</p><p>Single_Stack_IPv6_FullAddress::=0x02;</p><p>Single_Stack_IPv6_Prefix::=0x03;</p><p>Dual_Stack_IPv4_Preferred::=0x04;</p><p>Dual_Stack_IPv6_Preferred_FullAddress::=0x05;</p><p>Dual_Stack_IPv6_Preferred_Prefix::=0x06;</p><p>Also, it will be apparent to those skilled in the art that other values may be used in the actual implementation of this message.</p><p>The Service_Support field 804 is a composite field including all attributes necessary to support service provision in the WLAN. The actual content is service-specific, and an example of the content of this field is that described in Data Structure 1.</p><p>Also, the Tunnel_Setup field 805 is a composite field, and the same format as the Tunnel_Spec field 706 in the Service_Request message 203 is used.</p><p>Also, the last field of the WLAN_Request message 206 is the Security_Field 806 . This field uses security associations to fully protect the message as a whole. The algorithm used for the calculation of this field depends on the actual embodiment.</p><p>After receiving the WLAN_Request message 206 , the WLAN server 102 executes the WLAN service address management 207 . For example, if assignment of a local IPv6 address is requested by the home network authenticator 103, the WLAN server 102 finds an appropriate network session and assigns an IPv6 address to the terminal. Also, if necessary, the WLAN server 102 further updates the gateway (that is, assigns a new address to the firewall of the WLAN). Thereby, the mobile terminal 101 is able to access the service using this assigned local address.</p><p>The WLAN server 102 uses the information in the Service_Support field 804 to further enforce local admission control. As with the service provider network server 104, if any attribute exceeds the current capacity of the WLAN, the WLAN server 102 may intervene with the home network authenticator 103, for example, a reduction in bit rate or Attempts to make new settings for service details, such as updating the service time interval.</p><p>If the scheme of the tunnel based on the client is selected by the home network authenticator 103, the WLAN server 102 does not need to make any special settings. On the other hand, when a network-based tunnel scheme is used, the WLAN server 102 needs to identify an endpoint of the tunnel by using information from the MT_ID field 802 .</p><p>The WLAN server 102 uses the WLAN_Reply message 208 to reply to the WLAN_Request message 206 .</p><p>As the WLAN_Reply message 208, the same structure as the WLAN_Request message 206 shown in FIG. 8 is used. </p><p>The Home_Nework_ID field 801 and the MT_ID field 802 are copied directly from the corresponding WLAN_Request message 206 . These fields are used by the home network authenticator 103 to match pairs of request and reply messages.</p><p>In addition, the Address_Alloc field 803 in the WLAN_Reply message 208 contains local address information of the WLAN assigned to the mobile terminal 101 . As defined in the Address_Request field 307 in the MT_Request_A message 202A, the first octet of this field indicates the type of address. The next portion of this field contains the actual address assigned to the mobile terminal 101. For example, when an IPv6 address is assigned, the first octet is 0x02, and the next 32 octets contains the actual IPv6 address. address is included.</p><p>In addition, the Service_Support field 804 in the WLAN_Reply message 208 includes service attribute information defined in the WLAN_Request message 206 . If the WLAN has accepted these service attributes, the WLAN server 102 directly copies them from the WLAN_Request message 206 . On the other hand, if the WLAN server 102 cannot accept the attribute, it adds the attribute set to a new value in the WLAN_Reply message 208 and transmits a new proposal.</p><p>Also, the Tunnel_Setup field 805 in the WLAN_Reply message 208 is information of the tunnel to the mobile terminal 101 . Here, the type of tunnel used in the first octet and data specific to the type of tunnel in the next octet are indicated. For example, when Mobile IPv6 is used for data traffic, only the tunnel type exists in this field, and the address in the Address_Alloc field 803 is used as the care of address of the mobile terminal 101 . . On the other hand, when Mobile IPv4 is used, the tunnel type is included in the first octet in this field, followed by a foreign agent address allocated to the mobile terminal 101 .</p><p>After receiving the Service_Reply message 205 and the WLAN_Reply message 208 , the home network authenticator 103 aggregates the information from the WLAN server 102 and the service provider network server 104 . If the Service_Spec field 705 or the Service_Support field 706 includes a value of an attribute different from that in the Service_Request message 203 or the WLAN_Request message 206, it is necessary to contract the details of the service again. At this time, the home network authenticator 103 checks the new values proposed by the service provider network server 104 or the WLAN server 102, and if these new values can be accepted, the SPN_Config message 210 and Using the WLAN_Config message 211, the new setting is approved.</p><p>The Service_Request message 203 has no temporal correlation between the Service_Reply message 205, the WLAN_Request message 206, and the message pair of the WLAN_Reply message 208. That is, they are done in parallel, or they are done one by one depending on the implementation of the home network authenticator 103, respectively. For example, if the connection with the WLAN server 102 is idle, the home network authenticator 103 may make a decision to send the WLAN_Request message 206 instead of the Service_Request message 203 .</p><p>In addition, when a transfer is required again, an SPN_Config message 210 is sent from the home network authenticator 103 to the service provider network server 104 to confirm the new service parameters. In addition, the same message format as the Service_Request message 203 is used as the SPN_Config message 210 . In addition, if the same message format is not used, for example, some fields such as Address_Request may be omitted.</p><p>Moreover, tunneling information may be added as needed. For example, if a client based tunnel (eg, Mobile IP) is used, the care-of address of the mobile terminal 101 assigned by the WLAN server 102 is inserted into the Tunnel_Request field 308 . Also, when a network-based tunnel is used, the tunnel endpoint address or port number of the WLAN is transmitted in this message.</p><p>In addition, the WLAN_Config message 211 is used for the same purpose, and the home network authenticator 103 uses this message as necessary to receive confirmation of the new configuration from the WLAN server 102 . It is also possible that this information is further used to transmit tunnel information. For example, when a network-based tunnel is used, the tunnel endpoint address or port number of the service provider network 1003 is sent to the WLAN server 102 in this message, and then the WLAN server 102 ) instructs to establish a tunnel to the counterpart node (Correspondent node). On the other hand, when a client-based tunnel is used, the address of the terminal is included in this message, and as a result, the WLAN can open the firewall for data traffic.</p><p>Also, these two messages, the SPN_Config message 210 and the WLAN_Config message 211 are used by the home network authenticator 103 to invalidate the resources allocated to the mobile terminal 101 when the service session ends. It is clear to those skilled in the art that this is possible. For example, if the home network authenticator 103 verifies that the mobile terminal 101 is not already in the WLAN, it sends a WLAN_Config message 211 containing the Service_Support field 804 all set to zero. can send After receiving this kind of message, the WLAN server 102 releases all the resources allocated to the mobile terminal 101 and performs other appropriate operations.</p><p>The home network authenticator 103 sends an MT_Reply_B message 212B in reply to the MT_Request_B message 202B. This message is sent by the access point 105 or other ancillary device to the mobile terminal 101 as a message MT_Reply_A message 212A. In addition, the MT_Reply_A message 212A and the MT_Reply_B message 212B have the same content and format. The Network Element between the home network authenticator 103 and the mobile terminal 101 does not have access to the contents of these messages, and the access point 105 only re-encapsulates the entire message and transmits it. The MT_Reply_A message 212A or the MT_Reply B message 212B is encrypted by a security association shared between the mobile terminal 101 and the home network authenticator 103 . In addition, the MT_Reply_A message 212A is a reply to the corresponding MT_Request_A message 202A, and the access point 105 can grasp the mobile terminal 101 to be transmitted.</p><p>In addition, when the WLAN server 102 is on the path of the MT_Reply_B_message 212B, the WLAN_Config message 211 can be loaded on the message and transmitted. For example, if the WLAN server 102 is an AAA server that transmits the MT_Reply_B message 212B to the mobile terminal 101 using a diameter in the WLAN, the MT_Reply_B message 212B is sent to the diameter EAP-Answer AVP. It can be encapsulated. Meanwhile, the WLAN_Config message 211 may be encapsulated in another AVP within the same message. In addition, it is apparent to those skilled in the art that the same scheme can be used even when different transport protocols are used.</p><p>The MT_Reply_A message 212A has the same structure as that of the MT_Request_A message 202A shown in FIG. 3 . The Message_Type field 301 has the same format as the MT_Request_A message 202A, and an integer is used to indicate that this message is a response rather than a request. In addition, the Message_Length field 302 indicates the sum of the lengths of messages including the Message_Type field 301 . Also, the Domain_Name field 303 and the MT_ID field 304 in the MT_Reply_A message 212A are the same as the fields in the MT_Request_A message 202A. In addition, it is apparent to those skilled in the art that in practice these fields can be omitted in order to optimize the signaling.</p><p>Also, the Service_Request field 305 in the MT_Reply_A message 212A is used to contain service specific information set by the home network authenticator 103 based on the user's subscription information. For example, if the user requested an IMS service, the P-CSCF address is available. In addition, it is apparent to those skilled in the art that this field may include other information necessary for service provision. Also, the exact format of this field is service dependent.</p><p>Also, the Session_ID field 306 in the MT_Reply_A message 212A is copied directly from the MT_Request_A message 202A, but may actually be omitted if it is not requested by the mobile terminal 101 .</p><p>Also, the Address_Request field 307 in the MT_Reply_A message 212A contains the address assigned to the mobile terminal 101 . This is the source address that should be used by the service application. The first octet in this field is the address type, followed by the actual address. For example, if a prefix of an IPv6 address is assigned, the first octet is 0x03. Also, the next 32 octets contain the prefix information used by the mobile terminal 101 to form the actual IPv6 address, and may contain other address information such as, for example, WLAN gateway address, DNS server address, etc. do. These attributes follow the address information. In addition, the wildcard value of all 0 indicates that the mobile terminal 101 should use a local stateless mechanism to obtain actual address information.</p><p>In addition, the Tunnel_Request field 308 in the MT_Reply_A message 212A contains the setting of tunneling for accessing the service requested by the mobile terminal 101 . This depends on the tunnel type, and the first octet of this field indicates the type of tunnel to be used.</p><p>For example, when Mobile IPv6 is used for the tunnel type based on the client, the value becomes 0x06 so that the tunnel type is defined in the MT_Request_A message 202A. Following the type attribute are the care-of address and home agent address assigned by the WLAN and, if necessary, the security key. The address in the Address_Request field 307 becomes the home address assigned to the terminal.</p><p>In addition, when a network-based tunnel type is used, following the type attribute, the local endpoint address of the tunnel and a security key for the mobile terminal 101 to securely communicate with the endpoint exist.</p><p>The WLAN_ID field 309 in the MT_Reply_A message 212A is copied directly from the MT_Request_A message 202A. Also, in order to optimize the signaling, it can actually be omitted.</p><p>In addition, the Security_Field 310 of the MT_Reply_A message 212A is used to completely protect the entire message, and security association between the mobile terminal 101 and the home network authenticator 103 is used. Also, here, the same algorithm as the MT_Request_A message 202A should be used.</p><p>After receiving the MT_Reply_A message 212A, the mobile terminal 101 retrieves all necessary information and configures it accordingly, and can use this setting to initiate the actual service session 213 .</p><p>In practice, the mobile terminal 101 may request several services simultaneously, for example conducting a Voice-over-IP session in conjunction with a video streaming session. That is, it is possible to relate different service provider networks within the signaling. In the scenario of aggregating several service requests within the same message, the same mechanism and message structure as above can be used. For example, in the MT_Request_A message 202A, a plurality of settings of a Service_Request field 305 , a Session_ID field 306 , an Address_Request field 307 , and a Tunnel_Request field 308 may be present. These four fields are grouped, and each service requested by the mobile terminal 101 includes one group of these four fields. For example, if the MT_Request_A message 202A requested a Voice-over-IP session and a video streaming session, there are two groups of four fields listed.</p><p>After receiving the MT_Request_B message 202B containing the same content as the MT_Request_A message 202A, the home network authenticator 103 sends these four Retrieves information from each setting of a field. The home network authenticator 103 performs signaling for each of the requested services as above for a single service request. For example, the home network authenticator 103 sends a Service_Request message 203 to both the IMS subsystem and the network providing the streaming service. In addition, a WLAN_Request message 206 for each other service is transmitted to the same WLAN. The home network authenticator 103 can collect information and send only one message. If it is necessary to send multiple WLAN_Request messages 206 to the same WLAN, only one of them needs to make a local address assignment request.</p><p>The home network authenticator 103 integrates all service information into one MT_Reply_B message 212B according to the order of the requested service, and transmits it to the mobile terminal 101 through the access point 105 . The mobile terminal 101 can then use the information in the integrated MT_Reply_A message 212A to do its own address construction.</p><p>Also, when the mobile terminal 101 requests a plurality of services in parallel, different addresses may be assigned to the terminals from different service provider networks, and different tunnels may be further established in different service sessions. In this scenario, a special mid-layer processor is required. The service session identifier used in the Session_ID field 306 is used by the middle layer processor to multiplex the address and tunnel establishment.</p><p>The middle layer process in the mobile terminal 101 maintains a local database of addresses and tunnel information in different service sessions. When a service session is created in the mobile terminal 101, the middle layer 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. After receiving the MT_Reply_A message 212A containing both address and tunnel information, the middle layer processor creates a new entry in the database containing all information indexed (indexed) by the session identifier. When the service application needs to initiate a new connection session, it sends a request in which the session identifier is set to the middle-layer processor, and the middle-layer processor uses the session identifier to retrieve the corresponding address and tunnel information from the database. The address and tunnel information are used by the conventional stack, e.g., the IP layer, and appropriate bindings such as sockets are made to establish the connection.</p><p>Also, it is apparent to the person skilled in the art that in practice, for example, a WLAN without a controller such as a WLAN server 102 is possible. In this case, the mobile terminal 101 must use the local mechanism of the WLAN for address assignment and tunnel establishment. The home network authenticator 103 sets both the Address_Request field 307 and the Tunnel_Request field 308 in the MT_Reply_A message 212A to 0, and accordingly provides the mobile terminal 101 with, for example, DHCPv6, MIPv6, etc. You are forced to do the address configuration using a WLAN mechanism.</p><p>Also, in some cases, the mobile terminal 101 may wish to cancel service registration in the WLAN. It is apparent to those skilled in the art that the above mechanism can be used even when deregistration of a service is performed. The mobile terminal 101 may transmit an MT_Request_A message 202A in which a special value indicating the end of the service is set in the Service_Request field 305 . For example, the Service_Request field 305 may include a value such as "terminate.request.IMS.foo.bar.operator-name.operatorgroup.gprs". In addition, "terminate" before the "request" keyword is a flag for terminating the service indicated by the APN appended after the "request" keyword. In addition, 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 omit the Address_Request field 307 and the Tunnel_Request field 308 do.</p><p>The home network authenticator 103 processes the MT_Request_A message 202A as usual, and when the keyword "end" is found in the Service_Request field 305, the service session identifier is retrieved from the Session_ID field 306. take out Then, the home network authenticator 103 searches the database to find the session entry created at the time of service registration. This session entry stores information about service settings such as, for example, assigned addresses and tunnel settings. Using this information, the home network authenticator 103 sends a Service_Request message 203 to the service provider network server 104 and a WLAN_Request message 206 to the WLAN server 102 as usual. In these messages, the Service_Spec field 705 and the Service_Support field 804 are both set to zero.</p><p>The service provider network server 104 and the WLAN server 102 process the message as usual, read that the Service_Spec field 705 and the Service_Support field 804 are both set to 0, and determine that it is a service termination request. . These two servers search their database to find a service session entry created at the time of service registration, and release resources corresponding to the service session, such as an IP address or reserved bandwidth, for example.</p><p>After the home network authenticator 103 receives the notification from the service provider network 1003 and the WLAN, an MT_Reply_A message 212A is returned to the mobile terminal 101 . This message notifies that the service is terminated and the reserved resource is released. In this MT_Reply_A message 212A, the Service_Request field 305 includes information about the result. For example, the following value "removed.request.IMS.foo.bar.operator-name.operator-group.gprs" can be used in this field. Here, the "removed" keyword before the "request" keyword indicates the success of the service registration cancellation. Moreover, it is clear to those skilled in the art that special information may be included, for example, by adding information after the "removed" keyword.</p><p>In addition, in the process of providing a service to the mobile terminal 101, policy control may be included. For example, the terminal using the GPRS interface is given an access rate of 149 Kbps. When this terminal enters the WLAN, it transitions to use the WLAN interface to access the same service. Since WLAN provides a much higher air interface bandwidth, it is desirable for the terminal to enjoy a higher access rate (eg, 1 Mbps). In order to give the mobile terminal 101 a higher service rate, it is necessary to activate the policy control framework and to modify the corresponding policy settings, for example, the gateway filter. In the above example, for example, when a control point such as GGSN starts a service using a GPRS interface, the GGSN only needs to reserve a bandwidth of 149 Kbps for the service of the terminal. In addition, when the mobile terminal 101 registers a service session again using the WLAN service, the policy server must modify the GGSN setting to 1 Mbps. In addition, it is clear to those skilled in the art that other types of setting or control nodes are included in the policy control.</p><p>This kind of policy control should be done according to the user's subscription information, and therefore should be done within the home network domain. The present invention uses the home network authenticator 103 to handle service requests and addresses (tunnel setup). Thus, it has all the information necessary to determine the policy control, and can transfer this information from the home network authenticator 103 to the policy server of the home network domain. In this case, the policy server may use, for example, a policy control interface that enables operation to properly operate a corresponding node such as GGSN. In addition, the policy server can also notify other networks involved in service provision using the policy control framework, for example, the policy server in the home network domain sets a new access rate limit for the policy server in the WLAN. It is possible to notify, and as a result, the WLAN policy server can properly adjust the local admission management mechanism.</p><p>Also, Fig. 9 shows an embodiment of a message used between the home network authenticator 103 and the policy server. This message begins with an Operation field 901 . This field indicates the action performed by the policy server, and the possible values are as follows.</p><p>Install::=0x01</p><p>Remove::=0x02</p><p>Update::=0x03</p><p>When the home network authenticator 103 receives a request for a new service session from the mobile terminal 101 , it uses the value "Install" in the Operation field 901 . In addition, when the mobile terminal 101 terminates the service session, the home network authenticator 103 uses the "Removed" value in the Operation field 901 . In addition, when a service request from the mobile terminal 101 refers to an activated service session, the value "Update" is used. In addition, it will be apparent to those skilled in the art that other types of values may be used in practical implementations.</p><p>Also, 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 mobile user can be used.</p><p>Also, the third field is the MT_Location field 903 . This field is used by the policy server to retrieve a policy of a service based on location, for example, providing double the access rate when the terminal is in a given WLAN. This field is to include, for example, the WLAN identifier from the WLAN_ID field 309 of the MT_Request_A message 202A.</p><p>Also, the next field is the MT_Service field 904 . This field indicates what kind of service is accessed by the mobile terminal 101 . It is also possible that this field includes service session information. As an example of the content of this field, it is possible to add a session identifier to the APN.</p><p>Also, the next field is a Tunnel_Setting field 905 . This field indicates the tunnel establishment used by the mobile terminal 101 in the WLAN. The content of this field is the tunnel type, followed by the tunnel endpoint address and port number. Also, the exact format depends on the tunnel type. Also, the tunnel type to be used is defined in the Tunnel_Request field 308 of the MT_Request_A message 202A.</p><p>Also, the last field of the message is the MT_Address field 906 . This field is to contain the address used by the mobile terminal 101 in the WLAN. This is used by the policy server and allows you to set filtering rules to access the service.</p><p>Also, it is apparent to those skilled in the art that in practice the message fields need not be ordered in such a precise order as above. In addition, each field may include other information not described in this embodiment.</p>

<p>The present invention provides a management method for managing address assignment of a terminal in WLAN interconnection. By application of the present invention, an address is assigned to a mobile terminal based on the service requested by it and its subscription information, no access to local resources is required, and address management can be performed. In addition, the present invention provides a method for controlling tunnel establishment in WLAN interconnection. Here, the mobile terminal can support tunnel establishment based on network and client at the same time as service authorization. The present invention also provides an interconnection method in a policy control framework. By using the provided interface, it becomes possible to propagate service permission, address assignment, and tunnel setting information to the policy server, and it is possible to take appropriate actions to better distribute the service to the terminal. In all methods, address management, tunnel establishment and service authorization can be achieved by exchanging one round-trip message between the terminal and its home domain server. Thus, valuable signaling time or bandwidth is saved.</p>