JP4802238B2 - How to set up a network-based tunnel for mobile terminals in a local network interconnection - Google Patents

Description

  The present invention relates to the field of wireless data communications. More particularly, the present invention relates to setting up address management or tunneling in a wireless LAN environment for mobile users coming from other networks, where the WLAN is another, such as a WLAN using 3G networks or other wireless technologies. It can be used for inter-networking with a public wireless network existing in the management domain. The present invention, like a mobile terminal, can be used for address assignment, configuration, tunneling setting, etc. by WLAN and an inter-worked network. As a result, the mobile terminal can access services subscribed to in the WLAN.

  In WLAN inter-working, the terminal needs to be addressable so that it can access all the services that the terminal has subscribed to. If the service is transmitted over IP, the terminal should be associated with an IP address. In the mobile world, the point of attachment of a terminal changes frequently, and it is very likely that the terminal will traverse several domains during an active service session. In order to meet the requirements of terminal mobility, the address management mechanism requires that the terminal address be formed and updated each time the terminal changes the connection point.

  Mobile IP is a standardized technology published 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. To do. Thereby, when the user moves around in various IP networks, the user can be reached while using the same address. Mobile IP is not tied to the underlying link layer technology since mobility is managed at the IP level. Therefore, the same protocol stack can be applied to terminals in a 3G cellular network or a wireless LAN (for example, an 802.11 network). This kind of harmonized solution is particularly effective in the fusion of access technologies such as the interconnection of WLAN and 3G cellular networks.

  In the mobile IP, address management is performed by IP connection, and operation is impossible when the IP connection is not available. Furthermore, in the mobile IP, the terminal needs to have a home address and to know the home agent. This may not be obtained during the interconnect operation process, for example, when the terminal first starts to operate in a foreign WLAN.

  In the Mobile IPv6 draft, a method for setting a home address of a mobile node is introduced (Non-patent Document 2). For example, the terminal first generates a care-of address using DHCPv6 (Non-Patent Document 3), communicates with the home network using this address, and finally receives the final home address. Set. However, using a care-of address obtained from a WLAN does not always make the mobile node's home network reachable, so this is not possible in a WLAN interconnect. Furthermore, the configuration process for performing multiple exchanges consumes time and does not meet user expectations.

  Also, Diameter Mobile IPv6 adaptation (Non-Patent Document 4) showed a solution based on the configuration of AAA for mobile IPv6 address management. In this solution, AAA servers and destination and home network clients are used to perform address updates and agent discovery. That mechanism requires the mobile node to have a local IP connection for message exchange, such as being able to listen to router advertisement messages. However, this is not always possible with a foreign domain local policy.

  In addition, this mechanism may only be provided in situations where the address belongs to the mobile terminal's home domain, but in a WLAN interconnect, it will receive an address from another domain depending on the service the terminal is accessing. Will be used. Therefore, since the terminal does not have service request information, this cannot be supported by this mechanism. This mechanism is designed for a mobile IPv6 environment and is therefore inoperable on terminals without a Mobile IP stack.

Further, 3GPP provides a solution, GTP (Non-Patent Document 5) for managing terminal addressing and tunneling. GTP has two parts: GTPC for control and GTP-U for user data traffic. GTP operates on UDP and encapsulates user data in UDP packets. GTP is designed for GPRS (Non-Patent Document 6) networks and relies heavily on features of GPRS networks, such as GGSN, SGSN nodes, for example. This makes it difficult to deploy on a simple wireless access network (eg, WLAN).
"IP mobility support for IPv4" http://www.ietf.org/rfc/rfc3344.txt "Mobility support in IPv6" http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt `` Dynamic Host Configuration Protocol for IPv6 (DHCPv6) '' http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt "Diameter Mobile IPv6 Application" http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt `` GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface (Release 5) '' 3GPP TS 29.060 V5.3.0 (2002-09) ftp://ftp.3gpp.org/Specs/archive/29_series/ `` General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5) '' 3GPP TS 23.060 V5.2.0 (2002-06) ftp://ftp.3gpp.org/Specs/archive/23_series/ `` IP Multimedia Subsystem (IMS); Stage 2 (Release 5) '' 3GPP TS 23.228 V5.6.0 (2002-09) ftp://ftp.3gpp.org/Specs/archive/23_series/ "Diameter Base Protocol" http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt "PPP Extensible Authentication Protocol (EAP)" http://www.ietf.org/rfc/rfc2284.txt 3GPP project http://www.3gpp.org 3GPP2 project http://www.3gpp2.org "The Network Access Identifier" http://www.ietf.org/rfc/rfc2486.txt 「Numbering, addressing and identification (Release 5)」 3GPP TS 23.003 V5.3.0 (2002-06) ftp://ftp.3gpp.org/Sepcs/archive/23_series/ `` Port-Based Network Access Control '' IEEE Std 802.1X-2001 http://standards.ieee.org/getieee802/ “Diameter Extensible Authentication Protocol (EAP) Application” http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt "Diameter NASREQ Application" http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt `` IPv6 Stateless Address Autoconfiguration '' http://www.ietf.org/rfc/rfc2462.txt

  Usually, the WLAN and the interconnected network are in different management domains, which means that the address space is managed separately. Thus, if 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 can include, for example, IP address assignment, address registration, tunneling settings, and the like.

  Address registration is applied to perform any service delivered to terminals between WLANs. For example, in order to access an IMS (Non-Patent Document 7) service in a 3G network from a WLAN, it is necessary for the terminal to have an address belonging to the network that provides the IMS. A mobile terminal that performs access is required to be assigned a plurality of IP addresses.

  In WLAN, the terminal is not allowed to use any resources, such as sending and receiving normal data packets, before being granted authentication and authorization. For example, in normal mechanisms such as suggested in MIPv6, address construction may occur after successful authorization processing, but this type of approach is slow and cannot meet the requirements of some of the services . Appropriate information needs to be integrated into the access control message to assign the address before authorization. Address management is usually based on user subscription information and therefore needs to be managed by the mobile terminal's home network. For any external service, it is necessary to assign an address from a domain other than the home network. In this case, there is a need for a mechanism that allows the home network to perform address assignments and other information related to the domain.

  When a terminal changes its address, the QoS between terminals related to 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 terminal's new address needs to be indicated otherwise traffic may be blocked or interrupted.

  When the terminal enters the WLAN, the terminal must complete the authentication process and the authorization process and gain access to the resource. In the present invention, a solution to address management integrated into the access control mechanism is presented. With this integration, it is possible to assign the address of the terminal at the same time as permitting access. The terminal also reuses and extends the access control mechanism and thus does not need to implement any new protocol. The address configuration process is protected by the inherent encryption and protection of the access control process and therefore does not require extra security settings.

  The present invention further provides means for the terminal's home network to make address management arrangements with the network that provides the terminal's services. This type of exchange is a back-end process and is transparent to the mobile terminal and the WLAN. The result of the exchange is carried to the WLAN and mobile terminal using service authorization processing. If parallel access sessions exist on the same terminal, it is possible to request multiple addresses.

  The present invention also provides a method for a terminal to obtain an address associated with a session using a fine-grained service authorization process. Each session is allowed to transition to a new address using the address associated with it.

  Address management is also integrated into the policy control mechanism. Policy control provides a means for the terminal and its home network to configure the WLAN when needed after an address change. QoS or tunneling information is modified and supplied according to the new status using the channels available in the existing policy control process. This makes it possible to achieve a smooth transition in roaming time and minimize QoS interruptions.

  The present invention provides a method for controlling the setting of a tunnel in a local network interconnection. Here, the mobile terminal supports the setting of the tunnel based on the network and the client simultaneously with the service authorization. A given interface can be used to propagate service permissions, address assignments, and tunnels that set information to the policy server and take appropriate actions to better deliver the service to the terminal It becomes. In all methods, address management, tunnel setup and service authorization can be achieved with one round-trip message exchange between the terminal and its home network server. Thus, valuable signaling time and bandwidth are saved.

  The present invention is used for a WLAN to inter-work with other networks. The interconnected network can be another WLAN or a public cellular network, and in both cases the invention can be easily deployed. The present invention is used for the purpose of providing services suitable for address management and address transition (that is, mobility control).

  The application of the proposed mechanism (scheme) does not require any special interface or protocol to be implemented. This mechanism extends some of its attributes to reuse existing access control mechanisms and support the required functionality. In address assignment, the modification is integrated into the service authorization procedure. Since the authorization procedure is encrypted and protected by trust derived from authentication, the address information is also protected at the same security level and shown as part of the authorization information, in the same way as normal authorization information. Transfer is possible. 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 the EAP method can be used for permission. is there.

  When the terminal enters the WLAN, authentication and authorization are performed before the service is allowed to be used. In the authorization procedure, the terminal requests a service to be accessed, and this information is passed to the terminal's home network through the WLAN. The terminal's home network determines whether to allow the service based on the user's subscriber profile. Depending on the requested service, the terminal's home network further determines the address used for the service. For example, for an IMS service, the address needs to be allocated from the IMS address space, while for a local WLAN service, a locally obtained address is sufficient. In addition, tunneling information related to address management is identified.

  The address information is included in the permission information and is sent together with a permission success message. A part of this information reaches the WLAN, and a part reaches the terminal in the same way as a normal permission procedure. For example, it is necessary to send an address to the terminal so that the terminal can configure the address of the terminal itself. Also, if network tunneling is required, tunneling information is used by the WLAN.

  If an address change is required, the re-authorization procedure can use a quick update without going through the detailed service authorization procedure. When the terminal initiates access to the service, policy control is triggered and the address information is made available by the policy server in the terminal's home network, after which the policy server makes a policy decision based on the address information. Can be done. When the address changes, the policy server is notified to update the corresponding policy, thereby guaranteeing QoS and service provision.

To assist in understanding the invention, the following definitions are used.
“WLAN” refers to a wireless local area network and includes any number of devices to provide LAN services to mobile terminals through wireless technology.
“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).

“Mobile terminal” refers to a device used to access services provided by WLAN and other networks by wireless technology.
The “home network” refers to a network in which service subscription information of a mobile terminal (MT) is stored. In an interconnection scenario, the network to which the MT first joined or the subscription information of the MT is completely included. Can be a visited network that is allowed to access
The “service provider network” refers to a network that provides the service requested by the MT, and can be any network such as a home network, a WLAN, or an external network.

“Network element” refers to any device functioning in a network capable of executing information processing.
A “policy server” refers to a network element that performs a policy control function of a network domain. Policy control functions include, for example, local resource allocation, packet filter updates, routing updates, and the like. “Air interface” refers to any radio access technology for a mobile terminal to access a WLAN.

A “stream” is a collection of packets transferred in a network having a certain attribute in common.
“Traffic” is a collection of streams transferred within a network.
“Flow” refers to the network resources required for the data path and the data path used to carry the stream.
“QoS” refers to the term quality of service of a data stream or traffic.
"Message" refers to information exchanged between network elements for the purpose of controlling interconnection.

An “operation sequence” refers to a series of message exchanges between arbitrary network elements for interconnect control.
“Upper layer” refers to all entities that exist above the current entity and that process packets passed from the current entity.
“Client-based tunnel” refers to a tunneling mechanism in which one of the tunnel endpoints is a mobile terminal.
“Network-based tunnel” refers to a tunneling mechanism in which the end point of a tunnel exists in a network element other than a mobile terminal.

  In the following description, specific numbers, times, structures, protocol names, and other parameters are used in the description to fully understand the invention, but without such specific details. However, it will be apparent to those skilled in the art that the present invention may be practiced. In other instances, well-known components and modules are shown in block diagram form in order not to obscure the present invention unnecessarily.

  Mobility control is one of the most prominent problems in WLAN interconnects due to the high mobility of terminals. When the terminal moves, it is possible to force the connection point to use a non-local address. For example, for a 3G terminal entering a WLAN, a 3G domain address is required to access its home network service (eg, IMS service). When a terminal starts a service that is in a 3G network, an address is assigned according to a 3G scheme such as, for example, a GPRS service (NPL 6), and this address is tied to the 3G cellular interface of the terminal.

  When the terminal enters the WLAN domain, high throughput can be realized, and it is desirable to communicate using the WLAN interface. For example, a PDA with a dual interface (GPRS and IEEE 802.11) would want to use the GPRS interface on the road and use the IEEE 802.11 interface in the hot spot. When using a WLAN interface to access 3G services, the terminal needs to continue to use the same address obtained from the 3G interface. Otherwise, the terminal experiences a service interruption and must reinitialize the session. This is not desirable for the user. Since the address in use is not local to the WLAN, 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 allocation and tunnel setup. Note that only network entities that participate in signaling are shown to avoid confusion. The mobile terminal (101) is an entity that requests a service from the network. In the real world, it is possible to have several entities, such as a handset connected to a laptop computer via a Bluetooth link, but for simplicity, it is depicted as a set in FIG. It is.

  Within the WLAN function (1001), the access point (105) is an entity that provides WLAN access to the mobile terminal (101). Until it is authorized to use the WLAN service, the access point (105) blocks all data traffic from the mobile terminal (101) but allows only certain data packets. The channel is opened for access control signaling. The mobile terminal (101) communicates with the access point (105) through the wireless link (1011). As this link, any kind of wireless technology such as IEEE802.11, HiperLAN / 2, infrared, etc. can be used, and if similar access control technology is applicable, It does not exclude the use of other technologies, such as optical fiber, in the link.

  A WLAN management server (WLAN server) (102) exists as another entity in the WLAN. The WLAN server (102) is in charge of address space management and WLAN resource management, and exists on a WLAN gateway or is co-located with an access point (105) in a simple WLAN. The WLAN server (102) communicates with the access point (105) via the interface (1015). This is for WLAN resource control and service provision, eg, management of QoS over the air interface. In order to manage the WLAN, the server interacts with other entities of the WLAN such as, for example, a WLAN gateway (not shown) and a firewall.

  In the terminal's home network (1002), a home network authorizer (103) manages service authorization and address allocation. Both the access point (105) and the WLAN server (102) communicate with the home network authorizer (103) for service control information via the link (1012) and the link (1014), respectively. Physically, the link (1012) and the link (1014) can be the same, that is, even if they use the same protocol and are encapsulated in the same packet between the same terminals. Are logically separated.

  The mobile terminal (101) can request all services that it subscribes to. 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 a home network (1002) or WLAN, the service provider network (1003) will overlap these networks. Therefore, the control function can be linked to both.

  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 authorizer (103) communicates with the service provider network server (104) via the control interface (1013). In practice, a WLAN, home network (1002) or another network can be used as the service provider network (1003). In addition, when the service is provided by the home network (1002), this interface is an internal interface, and it is not necessary to use an accurate format or the same protocol as described in the embodiments described later. .

  FIG. 2 shows an example of an operation sequence for address management of WLAN interconnection using the above-described framework. This operation assumes that the mobile terminal (MT) (101) has already completed the WLAN association and authentication procedure (201). That is, the mobile terminal (101) and the access point (105) are mutually authenticated, and protection by encryption has already been performed for the next message exchange. When the mobile terminal (101) wants to access any service through the WLAN, it sends an MT_Request_A message (202A) to the access point (105) via the link (1011). Delivered to the network authorizer (103). This message is protected between end points (end-to-end) by a key generated from the authentication procedure (201). FIG. 3 shows an example of the message MT_Request_A message (202A).

  A message begins with a Message_Type field (301). This field identifies what type of message is encapsulated, eg, request, reply. 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 will be apparent to those skilled in the art that this field can adopt other formats if necessary.

  Following the Message_Type field (301), there is a Message_Length field (302). It contains information about the overall message length 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 12), for example, in a format of “UserID@home.domain.3gpp.org”. In order to protect the user identification information, a wild card value such as “roamed” is used for the UserID portion before the “@” symbol. The home domain information is used to route the message to the home network authorizer (103) of the mobile terminal (101).

  The above three fields, Message_Type field (301), Message_Length field (302), and 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 objective, the access point (105) can access the information contained in these fields. The field following the Domain_Name field (303) is protected by a security association between the mobile terminal (101) and the home network authorizer (103). For example, it can be the public key of the home network authorizer (103), ie the session key derived from the authentication procedure (201), and the index of the key used for message protection It is also possible to use the UserID portion of the Domain_Name field (303) to indicate

  After the Domain_Name field (303), there is an MT_ID field (304). This field contains information for uniquely identifying 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 TMSI (Non-Patent Document 13) obtained by the authentication procedure. The home network authorizer (103) uses this identifier to retrieve user subscription information. It will be apparent to those skilled in the art that other formats can be used for this field as long as the home network authorizer (103) can map it to the actual user identity.

  The next field is a Service_Request field (305). This field is used by the mobile terminal (101) to indicate the service that it wishes to access to the home network authorizer (103). Since the message is between the mobile terminal (101) and its home network authorizer (103), it is specific to a particular operator and network. For example, in a 3GPP network, this may be an APN for identifying the GGSN to use and the special service to access. It will be apparent to those skilled in the art that other formats can be used if the home network (1002) is of another type.

  Furthermore, other service request information can be added, for example, bandwidth requirements. Possible values for the field may be “2M.bandwidth.request.IMS.foo.bar.operator-name.operator-group.gprs”. The part after “request” is a standard APN identifying the service, and the part before “request” is a specific service request. The actual request attributes are service dependent and can be defined by the operator. The mobile terminal (101) can obtain information on the format from the SIM or USIM card.

  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 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 freed for reuse.

  In this embodiment, 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 Session_ID field (306) uniquely identify the service session in the home network authorizer (103).

  The Address_Request field (307) includes information related to an address allocation request from the mobile terminal (101). In this embodiment, a composite structure is used as shown in FIG. 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;
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

  It will be apparent to those skilled in the art that additional types are supported and other numbers can be used. The second part of this structure is the Suggestion_Length field (402). This field indicates the length of the next field Address_Suggestions field (403). The Address_Suggestions field (403) lists addresses that the mobile terminal (101) desires to be assigned. For example, an ongoing session uses an address and it is important that the same address be assigned so that the session is not interrupted.

  The Address_Suggestions field (403) may be a list of addresses. Each entry in the list begins with a one-octet type field indicating the type of address, eg, IPv4 or IPv6, followed by the actual address. In the home network authorizer (103) that does not support the terminal address presentation feature, the Suggestion_Length field (402) and the Address_Suggestions field (403) are silently ignored.

  A Tunnel_Request field (308) is present 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 a tunnel type identifier supported by the mobile terminal (101), and the value of that octet can be:

Network tunnel-general :: = 0x01;
Network tunnel-Mobile IPv4 :: = 0x02;
Client tunnel-general :: = 0x04
Client tunnel-Mobile IPv4 :: = 0x05;
Client tunnel-Mobile IPv6 :: = 0x06;
No tunnel :: = 0x08

  It will be apparent to those skilled in the art that other tunnel types can be defined and used in this field. The second octet of each entry indicates the tunnel direction. Possible values for this octet are:

Tunnel-from terminal :: = 0x01;
Tunnel-to terminal :: = 0x02;
Tunnel-bidirectional :: = 0x03;

  The first entry in the list indicates the preferred type of mobile terminal (101). The next field in the MT_Request_A message (202A) is the WLAN_ID field (309). This includes information identifying the WLAN to the home network authorizer (103) so that the home network authorizer (103) makes a location-based decision or mobile terminal It becomes possible to provide a service based on the location to (101).

  WLAN_ID can be acquired from an authentication procedure or information broadcast from an access point (105) such as an SSID in an IEEE 802 network. A local identifier for the mobile terminal (101) is also included for the access point (105) to identify the terminal. The last field is Security_Field (310). This field contains information for protecting the message. The exact algorithm used for the field is exchanged between the mobile terminal (101) and its home network authorizer (103). This can be determined by the user's subscription time and is stored in the terminal's SIM or USIM card. Further, it can be implemented as a software module, and can be downloaded whenever necessary.

  The fields in the MT_Request_A message (202A) do not need to follow the exact sequence as described above. For example, in practice, as long as the field identifiers are arranged at the forefront, the fields (304) to (309) are in any order. ) Can be arranged.

  In practice, any suitable mechanism can be used to transmit a message over link (1011). For example, in an IEEE 802.11 network, it is possible to implement it as an EAP message using EAPOL defined in IEEE 802.1x (Non-Patent Document 14).

  When the access point (105) receives this message, it retrieves the home domain information from the Domain_Name field (303) and uses the domain information such as making a DNS query, for example, It is possible to acquire the address of the authorizer (103). The access point (105) forwards the message to the corresponding home network authorizer (103) according to this information. For example, the WLAN has a central AAA server and the access point (105) forwards the message directly to the AAA server. The WLAN AAA server then analyzes the domain information and forwards the message to the actual home network authorizer (103). It is assumed that a secure link exists between the access point (105) and the home network authorizer (103). This can be done by setting in the authentication procedure (201) or by dynamically setting the security association derived from that process.

  The access point (105) does not need to participate in message processing and therefore does not need to implement the entire stack to parse the message. It simply needs to read the message type and perform the re-encapsulation and forwarding shown as a step in the MT_Request_B message (202B). The protocol used for the transfer can be any suitable AAA protocol (for example, EAP application for Diameter (Non-Patent Document 15) and NASREQ application for Diameter (Non-Patent Document 16)). It is. These protocols are already available at the access point (105) for authentication purposes. Therefore, the message MT_Request_A message (202A) is essentially sent from the mobile terminal (101) to the home network authorizer (103), as in the authentication procedure (201) between end points.

  FIG. 5 shows an example of a state machine of the home network authorizer (103). The home network authorizer (103) starts from the initial state (501), performs initialization () processing at the transition (/ intiate ()) (5001), and moves to the idle state (502). The initialization () process includes all the steps necessary to establish connections with other backend servers, security associations, etc. In fact, it will be apparent to those skilled in the art that other processes may be included depending on the configuration.

  When the home network authorizer (103) receives the MT_Request_B message (202B) transferred from the access point (105) in the transition (5002), it transitions to the message decoding state (503). FIG. 6 shows an example of the message decryption state (503). In the message decryption state (503), the home network authorizer (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 is corrupted or has been modified using Security_Field (310), the home network authorizer (103) The state machine transitions to the service rejection state (504) at transition (5004).

  From the MT_Request_B message (202B), the home network authorizer (103) can obtain information on terminal identification information from the MT_ID field (304) in step (6003). Using this identification information, the home network authorizer (103) retrieves the user's subscription information from its database and back-end server (eg, HSS of the 3GPP network). The home network authorizer (103) further analyzes the service request information obtained from the Service_Request field (305) in step (6004). The service request may include various embedded service specific information such as bandwidth, delay, instability, for example.

  In step (6005), in the home network authorizer (103), a determination is made as to whether to leave the user unserved using the user subscription information. If it is determined that the requested service should not be granted based on the user's subscription, the home network authorizer (103) sets a denial of service flag in step (6013) and the state machine , Transition (5004) to the service rejection state (504). If the service is allowed, the home network authorizer (103) searches the record for the terminal of the service with the session identifier received in the Session_ID field (306) in step (6007). To do.

  If there are records with the same session identifier, this means that this is a request for handover, and the terminal should be assigned the same address. As a result, the service session is not interrupted. Also, if there is no record, it means that it is a new request, and in step (6008) a record entry is generated and stored in the storage of the home network authorizer (103), eg Update the backend database such as HSS. The home network authorizer (103) further uses the service information to identify the service provider network (1003) and to set up a connection with the service provider network server (104).

  In step (6009), from the Address_Request field (307), the home network authorizer (103) obtains the address that the mobile terminal (101) wants to use. If the home network authorizer (103) does not want to support this feature due to operator policy or otherwise, this information can be silently ignored. The mobile terminal (101) should always use the last address assigned from the home network authorizer (103).

  Whether the home network authorizer (103) should be assigned an address, either locally or within the home network (1002), or within the service provider network (1003), from the requested service To decide. For example, if a user is only allowed to use a WLAN local service, an address is assigned within the WLAN, while a user who subscribes to a VPN service should be assigned with an address within that VPN. is there.

  In step (6010), the home network authorizer (103) retrieves the tunnel type supported by the mobile terminal (101) from the Tunnel_Request field (308). This information is used to set up the tunnel for service provision. The mobile terminal (101) can enumerate one or more tunnel types and make the first in the list the preferred type. The home network authorizer (103) needs to check with the service provider network server (104) to determine what type should be used. Further, for example, extra information such as a tunnel direction may be included.

  In step (6011), the home network authorizer (103) obtains identification information of the wireless LAN to which the mobile terminal (101) is currently related from the WLAN_ID field (309). Using this information, the home network authorizer (103) finds the corresponding WLAN management server (102). As part of the roaming agreement, this information can be stored in the home network authorizer (103) database and can be retrieved from the back-end server (eg, HSS). Is possible. After the server information is obtained, a secure link is established. This link is used for the next service message signaling. After obtaining all the information, the home network authorizer (103) creates a Service_Reqeust message (203) and a WLAN_Request message (205). This message is sent when the state machine of the home network authorizer (103) transitions to the standby state (504).

  FIG. 7 shows an example of the Service_Request message (203). This message starts from the Home_Network_ID field (701). This field contains information about the home network identifier of the mobile terminal (101) and can be the operator's name or a large network subsystem. The identifier must be globally unique, for example a network DNS name such as “network.operator.3gpp.org” is a good candidate for this identifier. The presence of home network information allows the service provider network server (104) to apply network policies, such as roaming agreements, to service requests.

  User profiles are managed by the home network (1002). Therefore, user information should not be sent to the service provider network server (104). However, it is also possible to attach user priority / grouping information to the message to allow better control of the service. This can also be associated with a home network identifier such as “goldmember.network.operator.3gpp.org”, for example. The service provider network server (104) can use this to distinguish users when providing services.

  The next field is the MT_ID field (702). This field contains information on the identifier of the mobile terminal (101) and is used by the home network authorizer (103) for service tracking. The identifier is assigned by the terminal's IMSI or home network authorizer (103) and may be a temporary ID unique to the service session. It should be consistent until the service session ends.

  Following the above field, there is a Session_ID field (703). It is a session identifier assigned by the terminal. The service provider network server (104) should keep a record of all currently ongoing session information, so if the session identifier is present in the database it will Means that the same address configuration should be used to avoid service interruptions. For example, if the 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.

  The Address_Request field (704) is the same as that of the MT_Request_A message (202A). This part indicates to the service provider network server (104) the type of address to be assigned, for example IPv6. Further, as in the Address_Request field (307) of the MT_Request_A message (202A), the address requested by the mobile terminal (101) is provided. If the service provider network server (104) does not want to support this function, this information can be ignored. If the home network authorizer (103) determines that an address need not be assigned from the service provider network (1003), this field is omitted.

  The Service_Spec field (705) is a compound field and contains information about specific requirements required from the home network authorizer (103) based on user subscription. What this field can do (data structure 1) is shown below.

Struct Service_Spec [
u_long bitrate_avg;
u_long bitrate_max;
int deliver_order;
int MTU_size;
double delay;
double jitter;
int priority;
int service_direction;
int QoS_type
struct timeval start_time;
struct timeval end_time;
];

  Among these attributes, bitrate_avg and bitrate_max are maximum bit rates that guarantee the requested service. The deliver_order attribute indicates whether delivery is performed in order. MTU_size specifies the maximum data unit size transferred for the service. The delay and jitter fields specify some basic QoS attributes for the service. The priority attribute indicates the handling priority of data traffic for this service. The service_direction attribute indicates whether the service is one-way or two-way. The attribute of QoS_type indicates a QoS scheme used for providing a service such as DiffServ or InterServ service equipped with 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. It will be apparent to those skilled in the art that the actual implementation structure may include other attributes specific to the service.

  After the Service_Spec field (705), there is a Tunnel_Spec field (706). This field includes tunnel information, which is similar to the Tunnel_Request field (308) of the MT_Request_A message (202A), but with some special 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 last field of the Service_Request message (203) is Security_Field (707). This field is used to protect the entire message with the security association between the home network authorizer (103) and the service provider network server (104) and is used for this purpose The exact algorithm depends on the embodiment.

  It will be apparent to those skilled in the art that the fields in the Service_Request message (203) do not have to be in the order described; in practice, the home network authorizer (103) and the service provider network server ( 104) can communicate in any suitable order for optimization of signaling.

  After receiving the Service_Request message (203), the service provider network server (104) performs a service address management (204) procedure. In this procedure, the service provider network server (104) obtains a session identifier included in Session_ID (703) and searches the database. If there is a session identifier for the same mobile terminal (101), the service provider network server (104) copies all information in the record, eg MT address, service details, etc. Is returned directly to the home network authorizer (103) as a reply message.

  If the session identifier does not exist, 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 Address_Request field (704) and assigns an appropriate address to the mobile terminal (101) based on the type of address specified in this field.

  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, a message indicating failure is displayed in the home network It is sent to the authorizer (103). An error code can be used to identify the cause of the failure. If the given attribute in the Service_Spec field (705) exceeds the current capability of the service provider network (1003), the service provider network server (104) Attempts to interact with the authorizer (103). This is because the same Service_Request message (203) with the Service_Spec field (705) modified to the value proposed by the service provider network server (104) is sent back to the home network authorizer (103). Achieved.

  The service provider network server (104) checks the Tunnel_Sepc field (706) for the matching tunnel type. Although there may be multiple matches, the service provider network server (104) should select the first match. For network-based tunnel types, the service provider network server (104) needs to provide tunnel endpoint information in the reply message. For client-based tunnels, the service provider network server (104) prepares information specific to the type of tunnel and includes it in the response information. For example, for a mobile IPv6 type scheme, the service provider network server (104) needs to assign a home agent to the mobile terminal (101) and include some security information in the reply message. Is also possible. Direction information (for example, one direction or both directions) is also added to the tunnel information field.

  The service provider network server (104) responds to the home network authorizer (103) with a Service_Reply message (205). The Service_Reply message (205) can use the same structure as the Service_Request message (203) as shown in FIG. The contents of the Home_Network_ID field (701), MT_ID field (702), and Session_ID field (703) are directly copied from the corresponding Service_Request message (203). If the signaling link is reused for multiple terminals, these fields are used by the home network authorizer (103) to match the request and reply message pairs.

  The contents of the Address_Request field (704) in the Service_Reply message (205) contains the address assigned to the mobile terminal (101), which is the address of the entry with the first octet indicating the length of the field in bytes. Could be a list. 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 permitted. For example, if the address field is all filled with 0, the mobile terminal can use a local WLAN mechanism (for example, IPv6 automatic allocation (Non-patent Document 17) or DHCP). (101) indicates that an address is formed.

  The contents of the Service_Spec field (705) in the Service_Reply message (205) includes attributes agreed by the service provider network server (104). When all attributes are approved by the service provider network server (104), it is the same as the Service_Spec field (705) in the corresponding Service_Request message (203). On the other hand, if not, it is the opposite proposal of the service provider network server (104) to the home network authorizer (103).

  The Tunnel_Spec field (706) in the Service_Reply message (205) contains the tunnel settings chosen by the service provider network server (104). The exact contents of this field are tunnel type specific and only one setting is required if a client based tunnel type is chosen. For example, if Mobile IPv6 is agreed, this field includes the address of the home agent assigned to the mobile terminal (101) and the security key for binding update authentication.

  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 will contain all the detailed information needed for each of the destination address, tunnel identifier, supported tunnel type, for example. .

  In parallel with the Service_Request message (203), the home network authorizer (103) transmits a WLAN_Request message (206) to the WLAN server (102). This message negotiates the settings necessary for providing services within the WLAN. FIG. 8 shows an example of this message.

  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). The Home_Network_ID field (801) includes an identifier of the subscriber's home network, and is passed to the WLAN server (102) when a certain network policy is applied to service provision. The MT_ID field (802) is used to track the location of the mobile terminal (101). It can be, for example, an identifier of an access point associated with a lower layer identifier (eg MAC address) of the mobile terminal (101).

  The Address_Alloc field (803) is a flag indicating whether it is necessary to assign a local address of the WLAN to the mobile terminal (101), and the type of address to be used. The home network authorizer (103) determines whether a local address is required based on the selected tunneling scheme. In the example, the following definition is used to indicate whether allocation is required by the first octet of this field.

No_Allocation :: = 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

  It will be apparent to those skilled in the art that other values can be used in the actual implementation of this message. The Service_Support field (804) is a composite field that includes all the attributes necessary to support service provision within the WLAN. The actual content is service specific, and an example of the content of this field is that described in Data Structure 1.

  The Tunnel_Setup field (805) is also a compound field, and uses the same format as the Tunnel_Spec field (706) in the Service_Request message (203). The last field of the WLAN_Request message (206) is Security_Field (806). This field uses a security association to fully protect the entire message. The algorithm used for the calculation of this field depends on the embodiment.

  After receiving the WLAN_Request message (206), the WLAN server (102) executes WLAN service address management (207). For example, if the local IPv6 address assignment is requested by the home network authorizer (103), the WLAN server (102) finds the appropriate network section and assigns the IPv6 address to the terminal. If necessary, the WLAN server (102) further updates the gateway (ie, assigns a new address to the WLAN firewall). As a result, the mobile terminal (101) can access the service using the assigned local address. The WLAN server (102) uses the information in the Service_Support field (804) to further perform local authorization control. Similar to the service provider network server (104), if any attribute exceeds the current capacity of the WLAN, the WLAN server (102) will communicate with the home network authorizer (103). Attempt to negotiate a new set of service details, such as, for example, bit rate reduction or changing the service time interval.

  If the client-based tunnel scheme is selected by the home network authorizer (103), the WLAN server (102) does not need to make any special settings. Also, if a network-based tunneling scheme is used, the WLAN server (102) needs to identify the tunnel endpoint using information from the MT_ID field (802).

  The WLAN server (102) responds to the WLAN_Request message (206) using the WLAN_Reply message (208). The WLAN_Reply message (208) uses the same structure as the WLAN_Request message (206) shown in FIG. The Home_Network_ID field (801) and the MT_ID field (802) are directly copied 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) includes information on the local address 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 part of the 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 are actually IPv6 addresses are included. 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 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) fails to accept the attribute, it adds a new value set attribute in the WLAN_Reply message (208) and transmits a new proposal.

  A Tunnel_Setup field (805) in the WLAN_Reply message (208) is information on a tunnel to the mobile terminal (101). It shows the type of tunnel used in the first octet and the data specific to the type of tunnel in the next octet. For example, when Mobile IPv6 is used for data traffic, only the type of tunnel 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, if Mobile IPv4 is used, this field contains the type of tunnel in the first octet, followed by the address of the foreign agent assigned to the mobile terminal (101).

  After receiving the Service_Reply message (205) and the WLAN_Reply message (208), the home network authorizer (103) integrates information from the WLAN server (102) and the service provider network server (104). If the Service_Spec field (705) or Service_Support field (706) contains different attribute values than those in the Service_Request message (203) or WLAN_Request message (206), the service details are negotiated again. There is a need. The home network authorizer (103) checks for new values proposed by the service provider network server (104) or the WLAN server (102) and if it can accept these new values, The SPN_Config message (210) is used to confirm the new setting, the WLAN_Config message (211).

  The message pair, the Service_Request message (203), the Service_Reply message (205), the WLAN_Request message (206), and the WLAN_Reply message (208), have no temporal correlation. They occur in parallel, i.e. depending on the implementation of the home network authorizer (103), respectively. For example, if the connection with the WLAN server (102) is idle, the home network authorizer (103) can make a decision to send the WLAN_Request message (206) instead of the Service_Request message (203). . Also, when the exchange is necessary again, the SPN_Config message (210) is sent by the home network authorizer (103) to the service provider network server (104) in order to confirm the new service parameter. Sent.

  The SPN_Config message (210) uses the same message format as the Service_Request message (203). If not used, some fields, such as Address_Request, are omitted. It is also possible to add tunneling information if necessary. For example, when 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). When a tunnel based on the network is used, the end point address and port number of the WLAN tunnel are transferred by this message.

  The WLAN_Config message (211) functions for the same purpose. The home network authorizer (103) uses this message to ask the WLAN server (102) to confirm the new settings if necessary. Furthermore, this information can also be used to transfer tunnel information. For example, if a network-based tunnel is used, the destination address and port number of the tunnel of the service provider network (1003) are transferred to the WLAN server (102) with this message, and then the WLAN server (102) Order the correspondent node to set up the tunnel. If a client-based tunnel is used, the terminal's address is included in this message so that the WLAN can open a firewall for data traffic.

  These two messages, SPN_Config message (210) and WLAN_Config message are used by the home network authorizer (103) to invalidate the resources allocated to the mobile terminal (101) when the service session is over. It will be apparent to those skilled in the art that (211) can be used. For example, if the home network authorizer (103) detects that the mobile terminal (101) is no longer in the WLAN, it will send a WLAN_Config message (211) containing the Service_Support field (804) all set to zero. put out. After receiving this type of message, the WLAN server (102) releases all resources allocated to the mobile terminal (101) and performs other appropriate operations.

  The home network authorizer (103) sends an MT_Reply_B message (212B) as a reply to the MT_Request_B message (202B). This message is forwarded to the mobile terminal (101) as a message MT_Reply_A message (212A) by the access point (105) or other accompanying device. The MT_Reply_A message (212A) and the MT_Reply_B message (212B) have the same contents and format. The network element between the home network authorizer (103) and the mobile terminal (101) does not access the content of these messages, and the access point (105) simply reencapsulates the entire message. And forward it. The MT_Reply_A message (212A) or the MT_Reply_B message (212B) is encrypted by the security association shared between the mobile terminal (101) and the home network authorizer (103). Since the MT_Reply_A message (212A) is a response to the corresponding MT_Request_A message (202A), the access point (105) can know which mobile terminal (101) to transfer to.

  When the WLAN server (102) is on the MT_Reply_B_message (212B) path, the WLAN_Config message (211) can be carried on the message. For example, if the WLAN server (102) is an AAA server that transfers a MT_Reply_B message (212B) to the mobile terminal (101) using a Diameter in the WLAN, the MT_Reply_B message (212B) is a Diameter-EAP. -While encapsulated in Answer AVP, it is also possible that the WLAN_Config message (211) is encapsulated in another AVP within the same message. It will be apparent to those skilled in the art that similar schemes can be used when other transport protocols are utilized.

  The MT_Reply_A message (212A) has the same structure as the MT_Request_A message (202A) shown in FIG. The Message_Type field (301) has the same format as that of the MT_Request_A message (202A), and an integer is used to indicate that this message is a response instead of a request. The Message_Length field (302) indicates the total length of messages including the Message_Type field (301). The Domain_Name field (303) and the MT_ID field (304) in the MT_Reply_A message (212A) are the same as those in the MT_Request_A message (202A). It will be apparent to those skilled in the art that in practice, these fields can be omitted to optimize signaling.

  The Service_Request field (305) in the MT_Reply_A message (212A) is used to contain information specific to the service set by the home network authorizer (103) based on user subscription information. For example, if the user requests an IMS service, this can be a P-CSCF address. It will be apparent to those skilled in the art that this field can include other information necessary to provide the service. The exact format of this field depends on the service.

  The Session_ID field (306) in the MT_Reply_A message (212A) is directly copied from the MT_Request_A message (202A), but if it is not requested by the mobile terminal (101), it can actually be omitted. . The Address_Request field (307) in the MT_Reply_A message (212A) includes an address assigned to the mobile terminal (101). It 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 an IPv6 address prefix is assigned, the first octet is 0x03. The next 32 octets also contain prefix information used by the mobile terminal (101) to form the actual IPv6 address, including other address information such as a WLAN gateway address, DNS server address, etc. It is also possible. These attributes follow the above address information.

  The all-zero wildcard value indicates that the mobile terminal (101) should use a stateless mechanism that does not result in any locality to obtain actual information. The Tunnel_Request field (308) in the MT_Reply_A message (212A) includes a tunneling setting for accessing a service requested by the mobile terminal (101). It depends on the type of tunnel and the first octet in this field indicates the type of tunnel used.

  For example, when Mobile IPv6 is used for the client-based tunnel type, the value is 0x06, as 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) is the home address assigned to the terminal. Following the type attribute, if a network-based tunnel type is used, there is a local endpoint address of the tunnel and a security key for the mobile terminal (101) to communicate securely with the endpoint. . The WLAN_ID field (309) in the MT_Reply_A message (212A) is directly copied from the MT_Request_A message (202A). In order to optimize signaling, it can actually be omitted.

  The Security_Field (310) of the MT_Reply_A message (212A) is used to completely protect the entire message. It uses a security association between the mobile terminal (101) and the home network authorizer (103). There, the same algorithm as in the MT_Request_A message (202A) should be used.

  After receiving the MT_Reply_A message (212A), the mobile terminal (101) retrieves all necessary information and configures accordingly. The mobile terminal (101) can use this setting to start the actual service session (213). In practice, the mobile terminal (101) can request several services at the same time, eg, performing a Voice-over-IP session with a video streaming session. This involves different service provider networks in the signaling. By gathering several service requests in the same message, it is possible to use the same mechanism and message structure as above in this scenario.

  For example, a plurality of sets of Service_Request field (305), Session_ID field (306), Address_Request field (307), and Tunnel_Request field (308) can exist in the MT_Request_A message (202A). The 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) requests a Voice-over-IP session and a video streaming session, there are two groups of four fields listed.

  After receiving the MT_Request_B message (202B) containing the same content as the MT_Request_A message (202A), the home network authorizer (103) corresponds to one specific service requested by the mobile terminal (101), Information is retrieved from each set of these four fields. 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) sends a Service_Request message (203) to both IMS subsystems. The network also provides a streaming service. While sending WLAN_Request messages (206) to different services, they reach the same WLAN. The home network authorizer (103) can collect information and send out only one message. If multiple WLAN_Request messages (206) need to be sent to the same WLAN, only one of them requires a local address allocation request.

  The home network authorizer (103) integrates all the service information into one MT_Reply_B message (212B) according to the order of the requested service, and passes it to the mobile terminal (101) via the access point (105). Transfer it. Thereafter, the mobile terminal (101) can perform its own address configuration using the information in the integrated MT_Reply_A message (212A). If the mobile terminal (101) requests a number of services in parallel, different addresses may be assigned to the terminal from different service provider networks, and different tunnels are set up in different service sessions. there is a possibility.

  In this scenario, a special mid-layer processer is required. A service session identifier, such as that used in the Session_ID field (306), is used by the middle layer processor to multiplex the address and tunnel settings. The middle tier processor in the mobile terminal (101) maintains a local database of address and tunnel information in different service sessions. If a service session is generated at the mobile terminal (101), the middle tier processor creates an identifier for it. This is a session identifier used in the Session_ID field (306) of the MT_Request_A message (202A). After receiving the MT_Reply_A message (212A) that contains all address and tunnel information, the middle tier processor creates a new entry in the database that contains all the information indexed by the session identifier.

  If the application of a service requires a new connection session to be initiated, it sends a request with a session identifier to the middle tier processor, which uses the session identifier to retrieve the corresponding address from its database. And search for tunnel information. The address and tunnel information is used by a normal stack, such as an IP layer, for example, and an appropriate binding, such as a socket, is made to make the connection.

  In fact, it will be apparent to those skilled in the art that a WLAN without a controller (ie, WLAN server (102)) is possible. In this case, the mobile terminal (101) must use a WLAN local mechanism for address assignment and tunnel setting. The home network authorizer (103) must set all of the Address_Request field (307) and the Tunnel_Request field (308) in the MT_Reply_A message (212A) to 0, which is sent to the mobile terminal (101). Thus, for example, the address configuration is forced to be performed using a WLAN mechanism such as DHCPv6 or MIPv6.

  In some cases, the mobile terminal (101) may wish to cancel service registration in the WLAN. It will be apparent 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 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 contain a value such as “terminate.request.IMS.foo.bar.operator-name.operatorgroup.gprs”, and the “ “Terminate” is a flag for terminating the service indicated by the APN attached after the “request” keyword.

  The Session_ID field (306) of the MT_Request_A message (202A) is set to the session identifier of the service to be terminated. For this type of MT_Request_A message (202A), the Address_Request field (307) and the Tunnel_Request field (308) can be omitted.

  As usual, the home network authorizer (103) processes the MT_Request_A message (202A), finds the “end” keyword in its Service_Request field (305), and retrieves the service session identifier from the Session_ID field (306). Get back. Then, the home network authorizer (103) searches the database for the session entry created at the time of service registration. This session entry stores information related to service settings such as assigned addresses and tunnel settings. Using this information, as usual, the home network authorizer (103) sends a Service_Request message (203) to the service provider network server (104), and sends a WLAN_Request message (206) to the WLAN server (102). ) Among 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 read that the Service_Spec field (705) and Service_Support field (804) are all set to 0, It can be seen that this is a service termination request. These two servers look for their database for service session entries created at the time of service registration and, for example, corresponding resources for the service session, such as IP address and reserved bandwidth To release.

  After the home network authorizer (103) receives 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 informs that the service has been terminated and the reserved resources have been released. In the MT_Reply_A message (212A), the Service_Request field (305) includes information regarding the result. For example, the following values can be used in this field: "Removed.request.IMS.foo.bar.operator-name.operator-group.gprs".

  Here, the “removed” keyword before the “request” keyword indicates the success of the service deregistration. It will be apparent to those skilled in the art that special information can be included, for example, adding information after the “removed” keyword.

  The process of providing the service to the mobile terminal (101) includes policy control. For example, a terminal using a GPRS interface is given an access rate of 149 Kbps. If this terminal enters the WLAN, the terminal transitions to use the WLAN interface to access the same service. Since WLAN provides much higher air interface bandwidth, it is anxious for terminals to enjoy higher access rates (eg, 1 Mbps). In order to give this higher service rate to the mobile terminal (101), a policy control framework needs to be activated to modify the corresponding policy settings, eg gateway filters. In the above example, for example, when a control point such as GGSN starts a service using the GPRS interface, the GGSN only needs to reserve a bandwidth of 149 Kbps for the service of the terminal. Also, when the mobile terminal (101) uses the WLAN service again to register a service session, the policy server should correct the GGSN setting to 1 Mbps. It will be apparent to those skilled in the art that other types of settings and control nodes are included in the policy control.

  This type of policy control should be done according to the user's subscription information and thus should be done in the home network domain. The present invention uses the home network authorizer (103) to handle service requests and addresses (tunnel settings). Thus, it has all the information necessary for policy control decisions and can pass such information from the home network authorizer (103) to the policy server in the home network domain. . The policy server can sequentially use, for example, a policy control interface for operating a corresponding node such as GGSN to operate appropriately. In addition, the policy server can use the policy control framework to notify other networks related to the service it provides, for example, the policy server in the home network domain Notifications can be made to the policy server in the WLAN with access rate restrictions, so that the WLAN policy server can adjust the local authorization management mechanism accordingly.

  FIG. 9 shows an example of a message used between the home network authorizer (103) and the policy server. The message starts from the Operation field (901). This field indicates the action performed by the policy server and possible values are:

Install :: = 0x01
Remove :: = 0x02
Update :: = 0x03

  When the home network authorizer (103) receives a request for a new service session from the mobile terminal (101), the value of “Install” is used in the Operation field (901). When the mobile terminal (101) ends the service session, the home network authorizer (103) uses the value “Removed” in the Operation field (901). When the service request from the mobile terminal (101) refers to an active service session, the value of “Update” is used. It will be apparent to those skilled in the art that other types of values can be used in actual implementations.

  The second field is an MT_ID field (902). This field contains the identifier of the mobile terminal (101) and may be, for example, the mobile user's IMSI.

  The third field is an MT_Location field (903). This field is used by the policy server to retrieve a policy for location-based services, such as providing twice the access rate if the terminal is in a given WLAN. is there. This field includes, 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 type of service is being accessed by the mobile terminal (101). In addition, it can include service session information. As an example of the contents of this field, an APN plus a session identifier can be used.

  The next field is a Tunnel_Setting field (905). This field indicates the setting of the tunnel used by the mobile terminal (101) in the WLAN. The contents of this field are the tunnel type, followed by the tunnel end address, port number, and the like. The exact format is tunnel type specific. The type of tunnel used is that 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 used by the policy server to allow rules for filtering to access the service. In fact, it will be apparent to those skilled in the art that the message fields need not follow the exact order as described above. Each field can further include extra information not described in this embodiment.

  As described above, the present embodiment provides a management method for managing terminal address assignment by interconnecting WLANs. Thus, the mobile terminal is assigned an address based on the service requested by the mobile terminal and its subscription information, and can perform address management without requiring access to local resources. Furthermore, the present embodiment provides a method for controlling the setting of a tunnel in a WLAN interconnection. Here, the mobile terminal supports the setting of the tunnel based on the network and the client simultaneously with the service authorization. Furthermore, the present embodiment provides an interconnection method in the policy control framework. A given interface can be used to propagate service permissions, address assignments, and tunnels that set information to the policy server and take appropriate actions to better deliver the service to the terminal It becomes. In all methods, address management, tunnel setup and service authorization can be achieved with a single round-trip message exchange between a terminal and its home domain server. Thus, valuable signaling time and bandwidth are saved.

  The present invention relates to the field of wireless data communications, and more particularly to setting up address management or tunneling in a local network environment for mobile users coming from other networks, and to inter-networking between wireless networks. It can be used when performing.

FIG. 2 is a block diagram showing an example of a network configuration used for management of mobile terminal address assignment, tunnel setting, and service arrangement in the WLAN interconnection of the present invention. Sequence chart showing an example of a message sequence for terminal address assignment, tunnel setting, and service arrangement used in the configuration shown in FIG. FIG. 2 is a data structure diagram showing an embodiment of a message configuration used by the mobile terminal in the message exchange shown in FIG. Data structure diagram showing an example of a format used by a mobile terminal for an address assignment request State transition diagram illustrating one embodiment of a home network authorizer in the framework shown in FIG. 1 for mobile terminal address assignment, tunnel setup, service arrangement in WLAN interconnection A flowchart illustrating an example of a flowchart that may be used to process a request message in a home network authorizer Data structure diagram showing one embodiment of the structure of a message used by the home network authorizer to negotiate service provider network server and mobile terminal service details, address assignments, and tunnel setup Data structure diagram illustrating one embodiment of the structure of a message used by the home network authorizer to negotiate service details, address assignments, and tunnel settings for the WLAN server and mobile terminal Data structure diagram illustrating one embodiment of the structure of a message used by the home network authorizer to make updates regarding the state of the mobile terminal of the policy server in the home network domain

Explanation of symbols

101 Mobile terminal (MT)
102 WLAN management server (WLAN server)
103 Home Network Authorizer 104 Service Provider Network Management Server (Service Provider Network Server)
105 Access Point 1001 WLAN Function 1002 Home Network 1003 Service Provider Network

Claims (26)

When a mobile terminal accesses a service provided in a home domain network of the mobile terminal or a service provided in a service provider network via the home domain network from a WLAN access network Because
A connection step in which the mobile terminal connects to the WLAN access network;
A home domain in which 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 is placed from the WLAN access network to the home domain network A sending step to send to the server;
The home domain server receives the tunnel establishment request message, and assigns an address for accessing a service requested by the mobile terminal based on the service request identifier and the mobile terminal identifier; and
Address management method. The assigning step comprises: accessing the service requested by the mobile terminal based on user subscriber information after the home domain server receives the tunnel establishment request message and before assigning the address. The address management method according to claim 1, further comprising a determination step of determining whether or not to permit the address. The address management method according to claim 2, wherein in the determination step, the home domain server makes an inquiry to a node in the home domain network or a node in the service provider network. The node in the home domain network that has received the inquiry or the node of the service provider network allocates the address for accessing the service requested by the mobile terminal, and the address is assigned to the home domain. The address management method according to claim 3 provided to a server. The address management method according to claim 1, further comprising: an adjustment step in which the home domain server adjusts QoS regarding the WLAN access network and a WLAN server connecting the home domain server. 6. The address management method according to claim 5, wherein the QoS adjustment is performed via a policy server that controls a policy of a network domain. The address management method according to claim 1, further comprising an acquisition step in which the mobile terminal acquires an address of the home domain server based on information of the home domain network. The address management method according to claim 1, further comprising an address transmission step in which the home domain server transmits the allocated address to the mobile terminal. A mobile terminal and a home domain server, wherein the mobile terminal provides a service provided from a WLAN access network in the home domain network of the mobile terminal, or a service via the home domain network An address management system for accessing services provided by a provider network,
The mobile terminal
A connection for connecting to the WLAN access network;
A tunnel establishment request message including a service request identifier for accessing a requested service and an identifier of the mobile terminal is transmitted from the WLAN access network to the home domain server arranged in the home domain network. The transmitter to
Have
The home domain server is
An allocation unit that receives the tunnel establishment request message and allocates an address for accessing a service requested by the mobile terminal based on the service request identifier and the mobile terminal identifier;
Having address management system. Determination that the allocator determines whether to permit access to the service requested by the mobile terminal based on user subscriber information after receiving the tunnel establishment request message and before allocating the address The address management system according to claim 9, further comprising a section. The address management system according to claim 10, wherein the determination unit makes an inquiry to a node in the home domain network or a node in the service provider network. The node in the home domain network or the node in the service provider network that has received the inquiry allocates the address for accessing the service requested by the mobile terminal, and assigns the address to the home 12. The address management system according to claim 11, which is provided to a domain server. 10. The address management system according to claim 9, wherein the home domain server further includes an adjustment unit configured to perform QoS adjustment between the WLAN access network and a WLAN server that connects the home domain server. 14. The address management system according to claim 13, wherein the QoS adjustment is performed via a policy server that controls a policy of a network domain. The address management system according to claim 9, wherein the mobile terminal further includes an acquisition unit that acquires an address of the home domain server based on information of the home domain network. The address management system according to claim 9, wherein the home domain server further includes a transmission unit that transmits the assigned address to the mobile terminal. A mobile terminal that accesses a service provided by a home domain network of the mobile terminal or a service provided by a service provider network via the home domain network of the mobile terminal from a WLAN access network Because
A connection for connecting to the WLAN access network;
A tunnel establishment request message including a service request identifier for accessing a requested service and an identifier of the mobile terminal is transmitted from the WLAN access network to a home domain server arranged in the home domain network. With the transmitter
Mobile terminal having. The mobile terminal according to claim 17, further comprising an acquisition unit that acquires an address of the home domain server based on information of the home domain network. The receiver further includes a receiving unit configured to receive an address assigned to access a service requested by the mobile terminal based on the service request identifier and the mobile terminal identifier from the home domain server. The mobile terminal according to. The home of a mobile terminal accessing a service provided by a home domain network of the mobile terminal or a service provided by a service provider network via the home domain network from a WLAN access network A home domain server located in the domain network,
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 is received from the mobile terminal, and based on the service request identifier and the mobile terminal identifier, A home domain server having an assigning unit for assigning an address for accessing a service requested by the mobile terminal. Determination that the allocator determines whether to permit access to the service requested by the mobile terminal based on user subscriber information after receiving the tunnel establishment request message and before allocating the address The home domain server according to claim 20, further comprising a unit. The home domain server according to claim 21, wherein the determination unit makes an inquiry to a node in the home domain network or a node in the service provider network. An address receiving unit that receives, from the node in the home domain network or the node in the service provider network, an address for accessing the service requested by the mobile terminal, assigned by the inquiry; 23. A home domain server according to claim 22. 21. The home domain server according to claim 20, further comprising a coordinating unit that performs a QoS adjustment between the WLAN access network and a WLAN server that connects the home domain server. 25. The home domain server according to claim 24, wherein the QoS adjustment is made via a policy server that controls network domain policies. 21. The home domain server according to claim 20, further comprising an address transmission unit that transmits the assigned address to the mobile terminal.