Method, device and system for obtaining local domain name

FIELD OF THE INVENTION

0001The present invention relates to the field of communications, and in particular, to a method, device and system for obtaining a local domain name.

BACKGROUD OF THE INVENTION

0002An Extensible Authentication Protocol (EAP) defines an authentication and key management architecture. An EAP authentication method is end-to-end authentication between an EAP client and an EAP server. An EAP packet can be borne by different protocols between different network entities on an authentication path. For example, an Authentication, Authorization and Accounting (AAA) protocol is adopted between an authenticator and the EAP server, which may be Diameter, Radius, or the like.

0003Currently, the EAP authentication is widely applied in network access control. As shown in <figref idref="f0001">FIG. 2</figref> which is an EAP authentication model: An Extensible Authentication Protocol (EAP)-client, EAP client, also called a peer or a supplicant (all of these names can be used interchangeably), is a function entity of a user terminal, and is configured to respond to the EAP authentication initiated by an authenticator on a link and implement the authentication between the EAP client and an EAP server. The authenticator is generally located on a Network Access Server (NAS), and is configured to initiate an EAP authentication process on the link, so as to implement the authentication between the EAP client and the EAP server. During the authentication process, the authenticator forwards an EAP message and performs underlying protocol conversion. For example, an EAP packet of the EAP client borne by a layer 2/3 protocol is received, a packet header of the layer 2/3 protocol is removed, and then the EAP packet is encapsulated through the AAA protocol and is sent to the EAP server. The EAP server, also called a backend authentication server, an AAA server, or a re-authentication server (during re-authentication), or called a domain server for short, is configured to provide the authenticator with an authentication service, that is, authenticate the EAP client.

0004When a node leaves a home domain, after the node performs a complete EAP authentication with a home server, a shared key is set up by the home domain server for the node (the EAP client) and a local domain server. When the node performs re-authentication in a local domain, the node can use the key to perform authentication with the local domain server, in which the process for generating the key of the re-authentication is as follows.

0005The shared key of the local domain server and the EAP client is called a Domain Specific Root Key (DSRK). The calculation method of the key is DSRK = KDF (EMSK, Domain ID | NULL | Peer_ID | Key_length), where "|" is a connecting symbol, for example, in A | B, if A represents a character string "good" and B represents "night", A | B represents "good night"; KDF represents a key derivation function, generally a unidirectional Hash function; EMSK is an extended master session key; Domain ID is a local domain name; Peer_ID is a user identity; and Key_length is a key length. Since the local domain server does not have the master key EMSK for generating the DSRK (which is saved on the home EAP server and the EAP client), the local domain server needs to obtain the master key EMSK from the home EAP server. The process of obtaining the master key EMSK is classified into an implicit process and an explicit process. The implicit process is an implicit EAP Re-authentication Protocol (ERP) bootstrapping process, which is included in a full authentication process, in which the local domain server requests, from the home domain server, informations relevant to a key such as the DSRK. The explicit process is an explicit ERP bootstrapping process, which is initiated by the EAP client when the EAP client does not have a local domain name, in which the local domain server may also incidentally request, from the home domain server, the informations relevant to a key such as the DSRK.

0006In the implementation of the present invention, the inventors find that the prior art has at least the following problems.

0007When the node hands over from one authenticator to a new authenticator during movement, or re-acknowledgement of it's accessing (re-authentication) is performed, the existing EAP architecture requires that the node should perform a complete EAP process with the home domain authentication server. Generally, one complete EAP authentication process requires multiple rounds interaction of a EAP authentication message. Moreover, the distance from the current authenticator to the home authentication server is long, and multiple hops exist. Since the EAP client does not know the local domain name to which the client belongs, a full authentication process must be performed again. Therefore, the node needs to spend a long time performing the complete authentication once, when the node leaves the home domain. Network accessing authentication and key management during the handover are one of main factors causing a handover delay, and the handover delay caused by the re-authentication performed by the node is one of the biggest problems of the mobile network.

0008<patcit id="pcit0001" dnum="EP2037712A2"><text>EP2037712 A2</text></patcit> describes a method, an apparatus and a system for obtaining a Media Independent Handover (MIH) service information. The method including: receiving an MIH service information request message from a mobile node; obtaining the MIH service information requested by the mobile node; and sending a response message to the mobile node, with the obtained MIH service information carried in the response message. So the MIH service information can be obtained dynamically.

0009<nplcit id="ncit0001" npl-type="b"><text>PATRICK MOTOROLA BCS M: "DHCP Relay Agent Information Option; rfc3046.TXT", IETF, 1 January 2001, XP015008829</text></nplcit>, describes a new DHCP option. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem.

0010<nplcit id="ncit0002" npl-type="s"><text>ANONYMOUS: 3GPP2-DRAFTS, UMB and HRPD/1x Interworking, 29 August 2008, pages 1-60, XP040484958</text></nplcit> describes IP Network operation for the Converged Access Network. The scope of this document covers support for handoff from UMB to HRPD/1x (Packet and Circuit) and handoff from HRPD/1x to UMB.

0011<nplcit id="ncit0003" npl-type="b"><text>NARAYANAN L DONDETI QUALCOMM V ET AL: "EAP Extensions for EAP Re-authentication Protocol (ERP); rfc5296.txt", IETF, 1 August 2008, XP015060283</text></nplcit> relates to an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control.

SUMMARY OF THE INVENTION

0012Accordingly, main objects of the embodiments of the present invention are to provide a method, device and system for obtaining a local domain name, to solve the problem that a user is incapable of obtaining a local domain name after full authentication, so that a User Equipment (UE) can perform fast re-authentication during a handover, thereby reducing the handover delay and improving the user experience.

0013The invention is defined by independent claims 1 and 2.

0014It can be seen from the specific implementation solutions according to the embodiments of the present invention that, the UE sends the DHCP request to the first server, in which the request carries the option for indicating returning the domain name of the local domain where the UE is located; and the first server, according to the DHCP request, carries, in the DHCP reply message to be returned to the UE, the domain name of the local domain where the UE is located, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

BRIEF DESCRIPTION OF THE DRAWINGS

0015<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">FIG. 1</figref> shows an EAP authentication model in the prior art provided by an example of the present invention;</li><li><figref idref="f0001">FIG. 2</figref> is a flow chart of a method for obtaining a local domain name according to an example of the present invention;</li><li><figref idref="f0002">FIG. 3</figref> is a flow chart of another method for obtaining a local domain name according to an example of the present invention;</li><li><figref idref="f0002">FIG. 4</figref> is a flow chart of a specific implementation for obtaining a local domain name according to an example of the present invention;</li><li><figref idref="f0003">FIG. 4a</figref> is a schematic structural view of a local domain name option in a DHCP Version 4 (DHCPv4) message according to an embodiment of the present invention;</li><li><figref idref="f0003">FIG. 4b</figref> is a schematic structural view of a local domain name option in a DHCP Version 6 (DHCPv6) message according to an embodiment of the present invention;</li><li><figref idref="f0004">FIG. 5</figref> is a flow chart of another specific implementation for obtaining a local domain name according to an embodiment of the present invention;</li><li><figref idref="f0005">FIG. 6</figref> is a schematic structural view of a device for obtaining a local domain name according to an embodiment of the present invention;</li><li><figref idref="f0005">FIG. 7</figref> is a schematic structural view of another device for obtaining a local domain name according to an embodiment of the present invention; and</li><li><figref idref="f0005">FIG. 8</figref> is a schematic structural view of a system for obtaining a local domain name according to an embodiment of the present invention.</li></ul>

DETAILED DESCRIPTION OF THE EMBODIMENTS

0016In order to the make the objectives, technical solutions, and advantages of the present invention more comprehensible, embodiments of the present invention are further described in detail in the following with reference to the accompanying drawings.

0017Apparently, the embodiments to be described are only a part rather than all of the embodiments of the present invention. Persons of ordinary skill in the art can derive other embodiments based on the embodiments of the present invention without creative efforts, which all fall within the scope of the present invention.

0018<figref idref="f0001">FIG. 2</figref> is a flow chart of a method for obtaining a local domain name according to an example not forming part of the present invention but being background knowledge useful for understanding the invention. The method includes: Step S200: A DHCP request of a UE is received, in which the request carries an option for indicating returning a domain name of a local domain where the UE is located.

0019The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0020The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network mainly refers to a visited network, and may also be a home network.

0021Step S202: The domain name of the local domain where the UE is located is obtained according to the DHCP request, and the domain name of the local domain where the UE is located is carried in a DHCP reply message to be returned to the UE.

0022The obtaining the domain name of the local domain where the UE is located is specifically as follows.

0023The domain name of the local domain where the UE is located is obtained from a first server itself; or after a second server receives the DHCP request and inserts the domain name of the local domain where the UE is located into the DHCP request, the domain name of the local domain where the UE is located is obtained from the DHCP request, into which the domain name of the local domain where the UE is located is inserted and which is forwarded by the second server, in which the domain name of the local domain where the UE is located is obtained by the second server from a third server.

0024The first server may be a DHCP server, in which the DHCP server is preferably located in a local network, and may also be located in a home network. The second server may be a NAS which is used as a relay or an agent of the DHCP server, and may also be a DHCP relay or a DHCP agent, or may implement a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent. The second server and the first server may be separated or coexist physically. The third server is a local EAP server, a home EAP server, an AAA server with an EAP function, or an AAA server with an ERP function.

0025The carrying, in the DHCP reply message to be returned to the UE, the domain name of the local domain where the UE is located specifically includes: setting the domain name of the local domain where the UE is located in a local domain name option, and encapsulating the local domain name option in the DHCP reply message to be sent to the UE.

0026It can be seen from the specific implementation solution according to the embodiment of the present invention that, the DHCP request of the UE is received, in which the request carries the option for indicating returning the domain name of the local domain where the UE is located; and the domain name of the local domain where the UE is located is obtained according to the DHCP request, and the domain name of the local domain where the UE is located is carried in the DHCP reply message to be returned to the UE, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0027<figref idref="f0002">FIG. 3</figref> is a flow chart of another method for obtaining a local domain name according to an example not forming part of the present invention but being background knowledge useful for understanding the invention.

0028Step S300: A DHCP request is sent to a first server, in which the request carries an option for indicating returning a domain name of a local domain where a UE is located.

0029The sending the DHCP request to the first server specifically includes the following step.

0030The DHCP request is directly sent to the first server; or the DHCP request is sent to a second server, and after the second server receives the DHCP request and inserts the domain name of the local domain where the UE is located into the DHCP request, the DHCP request is forwarded to the first server through the second server, in which the domain name of the local domain where the UE is located is obtained by the second server from a third server.

0031The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network mainly refers to a visited network, and may also be a home network.

0032Step S302: A DHCP reply message returned by the first server is received, and the domain name of the local domain where the UE is located is obtained from the reply message.

0033The sending the DHCP request to the first server specifically includes: sending, by the second server, the DHCP request to the first server, in which the first server and the second server are integrated on one server or disposed separately.

0034The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0035The first server may be a DHCP server, in which the DHCP server is preferably located in a local network, and may also be located in a home network. The second server may be a NAS which is used as a relay or an agent of the DHCP server, and may also be a DHCP relay or a DHCP agent, or may implement a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent, and may also be a server with an authenticator function and a DHCP relay/agent function. The second server and the first server may be separated or coexist physically.

0036It can be seen from the specific implementation solution according to the embodiment of the present invention that, the DHCP request is sent to the first server, in which the request carries the option for indicating returning the domain name of the local domain where the UE is located; and the DHCP reply message returned by the first server is received, and the domain name of the local domain where the UE is located is obtained from the reply message, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0037<figref idref="f0002">FIG. 4</figref> is a flow chart of a specific implementation for obtaining a local domain name according to an example not forming part of the present invention but being background knowledge useful for understanding the invention.

0038Step S400: After accessing a network, a UE performs EAP full authentication.

0039The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0040Specifically, the UE performs EAP access full authentication with a third server, and after the authentication succeeds, the following steps are performed. The third server is a local EAP server, a home EAP server, an AAA server with an EAP function, or an AAA server with an ERP function.

0041Step S402: The UE initiates a DHCP request message, in which the request carries an option for indicating returning a domain name of a local domain where the UE is located.

0042The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network mainly refers to a visited network, and may also be a home network.

0043The DHCP request message may be a DHCP DISCOVERY message or a DHCP REQUEST message of DHCPv4, or a DHCP Solicit message, a DHCP Request message, or a DHCP Information Request message of DHCPv6. Option information for requesting the local domain name is carried in the request message. For the DHCPv4, a code of a local domain name option is carried in a Parameter Request List; and for the DHCPv6, the code of the local domain name option is carried in an Option Request Option.

0044Specifically, for schematic structural views of the option for indicating information of returning the domain name of the local domain where the UE is located in the DHCP request message, reference can be made to <figref idref="f0003">FIGs. 4a and 4b</figref>.

0045<figref idref="f0003">FIG. 4a</figref> is a schematic structural view of a local domain name option in a DHCPv4 message, in which the option is used for indicating or bearing the information of returning the domain name of the local domain where the UE is located. Code represents a serial number of the option for distinguishing the option from other options. For example, when Code is "100", the option represents a local domain name option (a specified value may also be defined as a value of Code); when the value of Code is "101" (a specified value may also be defined as the value of Code), the option may also represent a sub-option of a relay-agent-information option, in which the sub-option is used for a DHCP relay/agent to insert local domain name information. Length represents a length of the option.

0046Local Domain Name is used for indicating the domain name of the local domain where the UE is located, an encoding format of which is the same as that of a common domain name, for example, www.example.com.

0047<figref idref="f0003">FIG. 4b</figref> is a schematic structural view of a local domain name option in a DHCPv6 message (a DHCPv6 local domain name option).

0048"OPTION_LOCAL_DOMAIN_NAME" represents a code value of the DHCPv6 local domain name option. For example, if "OPTION_LOCAL_DOMAIN_NAME" is "103", the option represents a local domain name option (a specified value may also be defined as the code value).

0049Length represents a length of the option.

0050Local Domain Name is used for indicating the domain name of the local domain where the UE is located, an encoding format of which is the same as that of a common domain name.

0051The option in the message is extended to carry the domain name of the local domain where the UE is located, which omits the process for the UE to perform authentication again after the EAP full authentication, so that the UE can perform fast re-authentication, thereby reducing a handover delay.

0052Step S404: A first server receives the DHCP request, and obtains, according to the request, the domain name of the local domain where the UE is located.

0053Step S406: The domain name of the local domain where the UE is located is carried in a DHCP reply message to be returned to the UE.

0054Specifically, the first server, for example, a DHCP server, sets the local domain name in a local domain name option according to the DHCP request, and then carries the local domain name option in the DHCP reply message to be sent to the UE.

0055The reply message may be a DHCP DISOFFER message or a DHCP ACK message of the DHCPv4, or a DHCP Advertise message, a DHCP Reply message, or a DHCP Information Reply message of the DHCPv6.

0056The first server may be located in a local network or a home network.

0057Step S408: The UE receives the DHCP reply message and obtains the local domain name from the message.

0058It can be seen from the specific implementation solution according to the embodiment of the present invention that, after the EAP full authentication performed by the UE succeeds, the UE initiates a DHCP request, in which the request carries information for indicating returning the domain name of the local domain where the UE is located, and the first server receives the DHCP request and carries the domain name of the local domain where the UE is located in the DHCP reply message to be returned to the UE, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0059<figref idref="f0004">FIG. 5</figref> is a flow chart of another specific implementation for obtaining a local domain name according to an embodiment of the present invention.

0060Step S500: After accessing a network, a UE performs EAP full authentication.

0061The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0062Specifically, the UE performs EAP access full authentication with a third server, and after the authentication succeeds, the following steps are performed.

0063Step S502: The third server sends an access success message containing local domain name information to a second server.

0064Specifically, the UE performs EAP access full authentication with a third server, and after the authentication succeeds, the following steps are performed. The third server is a local EAP server, a home EAP server, an AAA server with an EAP function, or an AAA server with an ERP function. The second server may be a NAS which is used as a relay or an agent of a DHCP server, implementing a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent, and may also be a server with an authenticator function and a DHCP relay/agent function. The second server and the first server may be separated or coexist physically.

0065Step S504: The second server receives and saves a domain name of a local domain where the UE is located.

0066Step S506: The UE initiates a DHCP request message, in which the request carries an option for indicating returning the domain name of the local domain where the UE is located.

0067The DHCP request message may be a DHCP DISCOVERY message or a DHCP REQUEST message of the DHCPv4, or a DHCP Solicit message, a DHCP Request message, or a DHCP Information Request message of the DHCPv6. Option information for requesting the local domain name is carried in the request message. For the DHCPv4, a code of the local domain name option is carried in a Parameter Request List; and for the DHCPv6, the code of the local domain name option is carried in an Option Request Option.

0068Specifically, for schematic structural views of the option for indicating information of returning the domain name of the local domain where the UE is located in the DHCP request message, reference can be made to <figref idref="f0003">FIGs. 4a and 4b</figref>. The schematic structural views of the option have been described in detail in the description of <figref idref="f0002">FIG. 4</figref> and will not be described herein again.

0069Step S508: The second server receives the DHCP request, inserts the domain name of the local domain where the UE is located into the request, and forwards the DHCP request to the first server.

0070Step S510: The first server obtains local domain name information of the network node from the request according to the received DHCP request, and carries the domain name of the local domain where the UE is located in a DHCP reply message to be returned to the UE.

0071It should be noted that, in step S508, the second server may also not insert the domain name of the local domain where the UE is located into the DHCP request when forwarding the DHCP request; and in step S510, when the DHCP server sends the DHCP reply message, the second server forwards the DHCP reply message, inserts the obtained domain name of the local domain where the UE is located into the reply message, and sends the domain name to the UE through the DHCP reply message.

0072Step S512: The UE receives the DHCP reply message and obtains the local domain name from the message.

0073It can be seen from the specific implementation solution according to the embodiment of the present invention that, after the EAP full authentication performed by the UE succeeds, the second server obtains the domain name of the local domain where the UE is located from the third server and stores the domain name of the local domain where the UE is located; when the UE initiates the DHCP request, the second server inserts the local domain name information into the DHCP request message to be sent to the first server; after receiving the DHCP request message, the first server obtains the local domain name information and carries, in the DHCP replay message to be sent to the UE, the local domain name information, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0074<figref idref="f0005">FIG. 6</figref> is a schematic structural view of a device for obtaining a local domain name according to an embodiment of the present invention.

0075The device for obtaining a local domain name includes a first receiving unit 600, an obtaining unit 602, and a first sending unit 604.

0076The first receiving unit 600 is configured to receive a DHCP request of a UE, in which the request carries an option for indicating returning a domain name of a local domain where the UE is located.

0077The obtaining unit 602 is configured to obtain, according to the DHCP request, the domain name of the local domain where the UE is located.

0078The first sending unit 604 is configured to carry, in a DHCP reply message to be returned to the UE, the domain name, obtained by the obtaining unit, of the local domain where the UE is located.

0079The obtaining unit 602 is specifically configured to obtain the domain name of the local domain where the UE is located from a second server, which receives the DHCP request and inserts the domain name of the local domain where the UE is located into the DHCP request, obtain the domain name of the local domain where the UE is located from the DHCP request, into which the domain name of the local domain where the UE is located is inserted and which is forwarded by the second server, in which the domain name of the local domain where the UE is located is obtained by the second server from a third server.

0080The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network refers to a visited network.

0081The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0082The first server is a DHCP server, in which the DHCP server is preferably located in a local network, and may also be located in a home network. The second server may be a NAS which is used as a relay or an agent of the DHCP server, and may also be a DHCP relay or a DHCP agent, or may implement a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent. The second server and the first server may be separated or coexist physically. The third server is a local EAP server, a home EAP server, an AAA server with an EAP function, or an AAA server with an ERP function.

0083The DHCP request message may be a DHCP DISCOVERY message or a DHCP REQUEST message of the DHCPv4, or a DHCP Solicit message, a DHCP Request message, or a DHCP Information Request message of the DHCPv6. Option information for requesting the local domain name is carried in the request message. For the DHCPv4, a code of a local domain name option is carried in a Parameter Request List; and for DHCPv6, the code of the local domain name option is carried in an Option Request Option.

0084Specifically, for schematic structural views of the option for indicating information of returning the domain name of the local domain where the UE is located in the DHCP request message, reference can be made to the description of <figref idref="f0003">FIGs. 4a and 4b</figref>, and the details will not be described herein again.

0085It can be seen from the specific implementation solution according to the embodiment of the present invention that, after EAP full authentication is implemented, the first receiving unit receives the DHCP request of the UE, in which the request carries a domain name of the local domain where the UE is located; the obtaining unit obtains the domain name of the local domain where the UE is located according to the DHCP request; and the first sending unit carries the domain name, obtained by the obtaining unit, of the local domain where the UE is located in the DHCP reply message to be returned to the UE, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0086<figref idref="f0005">FIG. 7</figref> is a schematic structural view of another device for obtaining a local domain name according to an embodiment of the present invention.

0087The device for obtaining a local domain name includes a second sending unit 702 and a second receiving unit 704.

0088The second sending unit 702 is configured to send a DHCP request to a first server, in which the request carries an option for indicating returning a domain name of a local domain where a UE is located.

0089The second receiving unit 704 is configured to receive a DHCP reply message returned by the first server, and obtain, from the reply message, the domain name of the local domain where the UE is located.

0090The second sending unit is specifically configured to send the DHCP request to the first server; or send the DHCP request to a second server, and after the second server receives the DHCP request and inserts the domain name of the local domain where the UE is located into the DHCP request, forward the DHCP request to the first server through the second server, in which the domain name of the local domain where the UE is located is obtained by the second server from a third server. The first server may be a DHCP server, in which the DHCP server is preferably located in a local network, and may also be located in a home network. The second server may be a NAS which is used as a relay or an agent of the DHCP server, and may also be a DHCP relay or a DHCP agent, or may implement a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent. The second server and the first server may be separated or coexist physically.

0091The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network refers to a visited network.

0092The device is a DHCP server, in which the DHCP request message may be a DHCP DISCOVERY message or a DHCP REQUEST message of the DHCPv4, or a DHCP Solicit message, a DHCP Request message, or a DHCP Information Request message of the DHCPv6. Option information for requesting the local domain name is carried in the request message. For the DHCPv4, a code of a local domain name option is carried in a Parameter Request List; and for the DHCPv6, the code of the local domain name option is carried in an Option Request Option.

0093Specifically, for schematic structural views of the option for indicating information of returning the domain name of the local domain where the UE is located in the DHCP request message, reference can be made to <figref idref="f0003">FIGs. 4a and 4b</figref>.

0094It can be seen from the specific implementation solution according to the embodiment of the present invention that, after EAP full authentication is implemented, the second sending unit sends the DHCP request to the first server, in which the request carries information for indicating returning the domain name of the local domain where the UE is located; and the second receiving unit receives the DHCP reply message returned by the first server, and obtains, from the reply message, the domain name of the local domain where the UE is located, which solves the problem that a user is incapable of obtaining a local domain name after full authentication, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0095<figref idref="f0005">FIG. 8</figref> is a schematic structural view of a system for obtaining a local domain name according to an embodiment of the present invention.

0096The system for obtaining a local domain name includes a UE 802 and a first server 804.

0097The UE 802 is configured to send a DHCP request to the first server after implementing EAP full authentication, in which the request carries an option for indicating returning a domain name of a local domain where the UE is located; and receive a DHCP reply message returned by the first server, and obtain the domain name of the local domain where the UE is located from the reply message.

0098The first server 804 is configured to receive the DHCP request of the UE after the EAP full authentication is implemented; and obtain the domain name of the local domain where the UE is located according to the DHCP request, and carry, in the DHCP reply message to be returned to the UE, the domain name of the local domain where the UE is located.

0099The system also includes a second server.

0100The second server 806 is configured to obtain, from a third server, the domain name of the local domain where the UE is located, and store the domain name of the local domain where the UE is located; and after receiving the DHCP request and inserting the domain name of the local domain where the UE is located into the DHCP request, forward the DHCP request to the first server.

0101The first server 804 is specifically configured to obtain, from the DHCP request forwarded by the second server, the domain name of the local domain where the UE is located.

0102The UE may be a user, a user terminal, an ERP client, a DHCP client, a peer, a supplicant, or the like, all of which have the same physical meaning in this solution.

0103The domain name of the local domain where the UE is located, called a local domain name for short, is a name of a domain where a current network to which the UE is attached is located. The current network refers to a visited network.

0104The first server may be a DHCP server, in which the DHCP server is preferably located in a local network, and may also be located in a home network. The second server may be a NAS, which is used as a relay or an agent of the DHCP server, and may also be a DHCP relay or a DHCP agent, or may implement a relay or agent function of the DHCP server through an internal module interface between an authenticator and a DHCP relay/agent, and may also be a server with an authenticator function and a DHCP relay/agent function. The second server and the first server may be separated or coexist physically. The third server is a local EAP server, a home EAP server, an AAA server with an EAP function, or an AAA server with an ERP function.

0105Through the system for obtaining a local domain name according to the embodiment of the present invention and interaction between each UE and the first server in the system, the problem that a user is incapable of obtaining a local domain name after full authentication is solved, so that the UE can perform fast re-authentication during a handover, thereby reducing a handover delay and improving the user experience.

0106Although the present invention is described above with some exemplary embodiments, the scope of the present invention is not limited thereto. Variations or replacements that can be easily thought of by persons skilled in the art within the technical scope of the present invention should be considered falling within the protection scope of the present invention, which is defined by the appended claims.