Patent Description:
<FIG> illustrates an architecture of the LTE mobile communication system.

As shown in <FIG>, the radio access network (EUTRAN) of the LTE mobile communication system is composed of an evolved base station (Evolved Node B, ENB or Node B) <NUM>, Mobility Management Entity (MME) <NUM>, and Serving Gateway (S-GW) <NUM>. Auser equipment (UEor terminal) 100mayconnect to an external network through the ENB <NUM>, S-GW <NUM> and PDN Gateway (P-GW) <NUM>.

Application Function (AF) <NUM> is an entity that provides session related information to user applications.

The PCRF <NUM> is an entity for controlling policies related to user QoS. Policy and charging control (PCC) rules corresponding to a specific policy are sent to the P-GW <NUM> for enforcement. The ENB <NUM> is a radio access network (RAN) node, which corresponds to the RNC of the UTRAN system or the BSC of the GERAN system. The ENB <NUM> is connected with the UE <NUM> through a wireless channel and functions similarly to the existing RNC or BSC.

In the LTE system, as all user traffic including real-time services like VoIP (Voice over IP) services is served by shared channels, it is necessary to perform scheduling on the basis of status information collected from UEs <NUM>. The ENB <NUM> performs this scheduling function.

The S-GW <NUM> provides data bearers, and creates and removes a data bearer under control of the MME <NUM>.

The MME <NUM> performs various control functions, and may be connected to multiple base stations.

Policy Charging and Rules Function (PCRF) <NUM> is an entity performing overall QoS and charging control functions for traffic. Document <CIT> is directed to an arrangement for improving the connectivity in a mobile telephone system. When a new SGSN performs handover for an MS in UMTS GPRS, the RNC notices itself that SGSN <NUM> is not or should not be reachable. The RRC Connection Release procedure is triggered. The RNC routes an initial request message from the MS to SGSN <NUM>. SGSN <NUM> will perform a normal Attach procedure or RAU procedure only that it uses the old P-TMSI and the old RA to determine that the MS previously was attached to SGSN <NUM>. <CIT> describes a mobile communication system, a radio network controller and a method. After an establishment of an RRC connection, a mobile station transmits an attach request signal to the RNC. At this time, an information element referred to as an IDNNS is set in the attach request signal. The IDNNS includes <NUM>-bit sequence information generated based on any of a TMSI, a P-TMSI, an IMSI and an IMEI as identification information for identifying the mobile station in a network.

For service provisioning in a wireless communication system described above, it is necessary to develop a method and apparatus that can provide services without increasing network load.

Aspects of the present disclosure are to address the above mentioned problems. The invention provides a method performed by a base station in a wireless communication system, according to claim <NUM>. The invention provides further a method performed by a terminal in a wireless communication system, according to claim <NUM>. The invention provides further a base station in a wireless communication system, according to claim <NUM>. The invention provides further a terminal in a wireless communication system, according to claim <NUM>.

In accordance with the present disclosure, a method performed by a base station in a wireless communication system is provided. The method comprises: receiving, from a first core network entity, information indicating that the first core network entity is unavailable; transmitting to a terminal, information indicating that the first core network entity is unavailable; receiving, from the terminal, a first message for requesting a registration, wherein the first message does not include information for identifying a core network entity; selecting a second core network entity as the first message does not include the information for identifying a core network entity; and transmitting, to the second core network entity, a second message including the first message. In accordance with the present disclosure, a method performed by a terminal in a wireless communication system is provided. The method comprises: receiving from a base station, information indicating that a first core network entity is unavailable; transmitting, to the base station which received information indication that the first core network entity is unavailable, a first message for requesting a registration, wherein the first message does not include information for identifying a core network entity; and receiving, from a second core network entity, a second message as a response to the first message, wherein the first message not including the information for identifying the core network entitytriggers the base station to select the second core network entity. In accordance with the present disclosure, a base station in a wireless communication system is provided. The base station comprises: a transceiver; and a controller configured to: receive, from a first core network entity via the transceiver, information indicating that the first core network entity is unavailable, transmit to a terminal, information indicating that the first core network entity is unavailable; receive, from the terminal via the transceiver, a first message for requesting a registration, wherein the first message does not include information for identifying a core network entity, select a second core network entity as the first message does not include the information for identifying a core network entity, and transmit, to the second core network entity via the transceiver, a second message including the first message. In accordance with the present disclosure, a terminal in a wireless communication system is provided. The terminal comprises: a transceiver; and a controller configured to: receive from a base station, information indicating that a first core network entity is unavailable; transmit, via the transceiver to the base station which received information indication that the first core network entity is unavailable, a first message for requesting a registration, wherein the first message does not include information for identifying a core network entity, and receive, from a second core network entity via the transceiver, a second message as a response to the first message, wherein the first message not including the information for identifying the core network entity triggers the base station to select the second core network entity.

According to an example not being part of the claimed invention, it is possible to provide a suitable service to a sender terminal making a CS service request to a receiver terminal having subscribed only to a PS service without increasing network load.

According to another example not being part of the claimed invention, even when a need for an emergency call is generated in a user equipment engaged in a normal call, it is possible to provide a service satisfying emergency call requirements.

According to an embodiment, when the network is congested, it is possible to provide services with reduced network load for congestion resolution.

In the following description of embodiments of the present disclosure, detailed descriptions of well-known functions and structures incorporated herein may be omitted to avoid obscuring the subject matter of the present disclosure.

In the drawings, some elements are exaggerated, omitted, or outlined in brief, and thus may be not drawn to scale. The same reference symbols are used throughout the drawings to refer to the same or like parts.

The following description of embodiments of the present disclosure is focused on Third Generation Partnership Project (3GPP) LTE systems. However, it should be apparent to those skilled in the art that the subject matter of the present disclosure is also applicable to other communication/computer systems having a similar technical basis and system configuration without significant modification. For example, the description related to the LTE system may be applied to the UTRAN/GERAN system having similar system architecture. In this case, the ENB (RAN node) maybe replaced with the RNC/BSC, the MME may be replaced with the SGSN, the S-GW may be omitted or be included in the SGSN, and the P-GW may correspond to the GGSN. Bearers in the LTE system may correspond to PDP context in the UTRAN/GERAN system. In various embodiments, each communication entity may include a transceiver unit to exchange signals with another entity, and a control unit to control the transceiver unit and perform operations on the basis of signals exchanged through the transceiver unit. In various embodiments, a user equipment may include a display unit to present a visual signal to a user.

In most cases, users wishing to receive wireless communication services subscribe to both circuit switched voice network (CS) services and packet switched data network (PS) services.

In one example, it may be assumed that a particular user has a subscription to only a PS service. A user having only a PS service subscription may receive an SMS service but may be not allowed to receive a CS service without a separate measure. That is, it may be assumed that a particular user is allowed to receive a PS data service and SMS service but is not allowed to receive a CS service such as a voice call (such a user is referred to as a PS-only-with-SMS user).

When a user equipment for a PS-only-with-SMS user is registered with an operator network, the operator network may provide a data service and SMS service to the PS-only-with-SMS user. In this case, a mobile terminating CS service request (e.g. a voice call) may be issued to the PS-only-with-SMS user. For example, a random call for advertisement or promotion may be placed without consideration of a recipient phone number. A voice call may be wrongly placed to a phone number that had been previously assigned to a voice call subscriber and has been reassigned to a PS-only-with-SMS subscriber.

As such, when a mobile terminating CS service request (voice call) is issued to a PS-only-with-SMS user, the network may have to perform signaling such as subscriber location identification and paging. However, as the PS-only-with-SMS user cannot receive a CS service like a voice call, such a signaling procedure is useless but merely increases network load.

To solve the above problem, a procedure is proposed as follows. When a mobile terminating CS service request is issued to a recipient having registered as a PS-only-with-SMS user, the operator network may determine that the user equipment is detached from a CS service (i.e. reject voice call or disallow CS service). More specifically, the following schemes may be used.

<FIG> illustrates a procedure for signal exchange according to the first example, wherein Home Location Register (HLR) is responsible for determination.

At operation <NUM>, a first user equipment (UE1) <NUM> is registered as a PS-only-with-SMS terminal in at least one of the MME <NUM>, MSC <NUM> and HLR <NUM>. Here, the UE1 <NUM> registered as a PS-only-with-SMS terminal may receive only a PS data service or a SMS service. PS-only-with-SMS may be given to a user equipment not allowed to receive a CS service.

At operation <NUM>, a second user equipment (UE2) <NUM>, being unaware that the UE1 <NUM> is a PS-only-with-SMS terminal, makes a voice call to the UE1 <NUM>. Here, in addition to a voice call, a request for any CS service may be issued.

At operation <NUM>, the UE2 <NUM> sends a request for placing a voice call destined for the UE1 <NUM> to Gateway Mobile Switching Center (GMSC) <NUM>.

Upon reception of the voice call request, at operation <NUM>, to find anMSC/VLR at which the corresponding subscriber is located, the GMSC <NUM> transmits a Send Routing Information (SRI) Request message to the HLR <NUM>. This message may include a service indicator indicating the requested service (voice call or SMS, or CS service other than SMS).

At operation <NUM>, the HLR <NUM> checks whether the request destined for the UE1 <NUM> is SMS according to UE registration information and examines subscription information of the UE1 <NUM>. If the request destined for the UE1 <NUM> is SMS, the HLR <NUM> may forward the request to the MSC <NUM> in which the UE1 <NUM> is registered.

If the request destined for the UE1 <NUM> is non-SMS (CS service or voice call), the HLR <NUM> may regard the UE1 <NUM> as being detached from the requested service.

To this end, at operation <NUM>, the HLR <NUM> sends a message indicating call rejection as a response to SRI to the GMSC <NUM>. The call reject message may include information notifying PS-only-with-SMS subscription. At operation <NUM>, a Send Routing Information Response message may be used. Another type message may also be used.

Upon reception of a negative response, at operation <NUM>, not to retry paging, the GMSC <NUM> stops the paging retry timer.

At operation <NUM>, the GMSC <NUM> sends a notification indicating failure of a voice call (CS service other than SMS) attempt to the sender network, which then notifies the sender (UE2 <NUM>) that the request for a CS service other than SMS (voice call) is denied because of recipient's PS-only-with-SMS subscription and an SMS service is available. The GMSC <NUM> may directly send such notification to the sender terminal <NUM>, or may send such notification to a corresponding to MSC of the sender network and the MSC may forward the notification to the sender terminal <NUM> via RNC (BSC). The sender terminal <NUM> may store the received information or notify the user of the same. The sender terminal <NUM> may notify the user of the received information by means of sound output or screen output.

<FIG> illustrates another procedure for signal exchange according to the first example.

Referring to <FIG>, at operation <NUM>, a first user equipment (UE1) <NUM> is registered as a PS-only-with-SMS terminal in at least one of the MME <NUM>, MSC <NUM> and HLR <NUM>. Here, the UE1 <NUM> registered as a PS-only-with-SMS terminal may receive only a PS data service or a SMS service.

At operation <NUM>, a second user equipment (UE2) <NUM>, being unaware that the UE1 <NUM> is a PS-only-with-SMS terminal, makes a voice call to the UE1 <NUM>.

At operation <NUM>, the UE2 <NUM> sends a voice call request to the GMSC <NUM>. At operation <NUM>, the GMSC <NUM> transmits an IAM message to the MSC <NUM> at which the UE1 <NUM> is located. The IAM message may include a service indicator indicating the requested service (voice call or SMS, or CS service other than SMS).

At operation <NUM>, theMSC <NUM> checks whether the request destined for the <NUM> is SMS. If the request destined for the E1 <NUM> is SMS, the MSC <NUM> sends a paging request to the MME <NUM> in which the UE1 <NUM> is registered. If the request destined for the UE1 <NUM> is a CS service (e.g. voice call), at operation <NUM>, the MSC <NUM> sends a message indicating that the UE1 <NUM> is registered as a PS-only-with-SMS terminal to the GMSC <NUM>. Here, this message may be a call reject message, which may include a cause of rejection. At operation <NUM>, the MSC <NUM> may use an RCH message or another type message to notify that the UE1 <NUM> is registered as PS-only-with-SMS.

After reception of a negative response, the GMSC <NUM> performs operation <NUM> and operation <NUM>, which are identical respectively to operation <NUM> and operation <NUM> in <FIG>.

At operation <NUM>, a first user equipment (UE1) <NUM> is registered as a PS-only-with-SMS terminal in at least one of the MME <NUM>, MSC <NUM> and HLR <NUM>. Here, the UE1 <NUM> may receive only a PS data service or a SMS service.

At operation <NUM>, a second user equipment (UE2) <NUM>, being unaware that the UE1 <NUM> has a PS-only-with-SMS subscription, makes a voice call to the UE1 <NUM>.

At operation <NUM>, the MSC <NUM> sends a paging request message to the MME <NUM>. Here, the paging request message may be a SGs_Paging_Req message, which may include an indicator to a service to be provided by paging.

At operation <NUM>, theMME <NUM> checks whether the request destined for the UE1 <NUM> is SMS. If the request destined for the UE1 <NUM> is SMS, the MME <NUM> may perform further processing.

If the request destined for the UE1 <NUM> is a CS service other than SMS (e.g. voice call), at operation <NUM>, the MME <NUM> sends a message indicating that the UE1 <NUM> is registered as a PS-only-with-SMS terminal to the MSC <NUM>. Here, this message may be a paging reject message, which may include a cause of rejection. The MME <NUM> may also use a SGs paging reject message or another type message.

Upon reception of a negative response such as paging reject, at operation <NUM>, not to retry paging, the MSC <NUM> stops the paging retry timer.

At operation <NUM>, the MSC <NUM> notifies the GMSC <NUM> of voice call rejection. Here, a call reject message including a cause of rejection may be sent to the GMSC <NUM> to notify the sender network of failure of a voice call attempt.

Thereafter, operation <NUM> and operation <NUM> in the sender network are performed in a manner identical respectively to operation <NUM> and operation <NUM> in <FIG>.

When a user equipment wishes to receive an emergency service, generation of an emergency bearer rather than a normal bearer is needed. In most cases, a typical normal bearer cannot be converted to an emergency bearer. When a user requests an emergency service, the operator network must set up an emergency call within a time duration set by local or government regulations.

Meanwhile, the maximum number of simultaneously activatable bearers in a user equipment may be limited according to implementation. Typical user equipments may simultaneously activate up to one, three or five bearers. In a user equipment, the number of simultaneously active bearers may exceed the maximum number of bearers supportable by the user equipment when an emergency call is placed in a state wherein the number of normal bearers currently active for system attachment has reached the maximum number of supportable bearers, or when multiple bearers needed to provide an emergency service are simultaneously created (for example, while the maximum number of supportable bearers is three, the number of active normal bearers is two and the number of emergency bearers needed is two). In this case, for emergency service provisioning, it is necessary to release normal bearers and create emergency bearers.

In consideration of the maximum number of supportable bearers, the number of currently active normal bearers, and the number of bearers needed for an emergency call or service, the user equipment may perform normal bearer cleanup first and then perform emergency bearer setup, or may simultaneously issue an emergency bearer setup request and a normal bearer cleanup request.

That is, when an emergency service is needed, the user equipment may send a normal bearer deactivation request to the network, or may locally deactivate normal bearers and notify the core network of a bearer context state through TAU. In the event that the core network (e.g. MME) is aware of the maximum number of bearers supportable by a user equipment, when the user equipment issues an emergency bearer creation request, the core network may automatically perform normal bearer cleanup for the user equipment. More specifically, the following schemes may be used.

<FIG> illustrates a procedure for signal exchange according to the second example.

Specifically, <FIG> depicts emergency service provisioning through the attach procedure.

Referring to <FIG>, in the second example, a UE <NUM> may exchange signals with a network composed of the MME <NUM>, S-GW <NUM>, P-GW <NUM> and HSS <NUM>. The UE <NUM> may exchange signals with the network via a base station (ENB).

At operation <NUM>, the UE <NUM> detects a user request for an emergency service.

At operation <NUM>, the UE <NUM> identifies the number of currently active bearers. Here, the number of currently active bearers may be the number of normal bearers. The UE <NUM> may determine whether some or all of the currently active bearers are to be deactivated on the basis of the number of currently active bearers, the number of bearers to be used for the emergency service, and the number of simultaneously supportable bearers. The UE <NUM> may determine that the number of simultaneously active bearers fails to accommodate the number of bearers to be used for the emergency service.

If there is no need to deactivate some or all of the currently active bearers, the UE <NUM> may exchange signals with the MME <NUM> to establish a call for the emergency service.

If some or all of the currently active normal bearers are to be deactivated, at operation <NUM>, the UE <NUM> performs local detach. Here, the UE <NUM> may autonomously conduct the local detach procedure.

At operation <NUM>, the UE <NUM> performs a re-attach procedure for the emergency service in cooperation with the MME <NUM>. This procedure maybe initiatedby sending an attach request, and the attach request may include an indication to the service or call type.

Upon reception of the attach request from the UE <NUM>, at operation <NUM> and at operation <NUM>, the core network identifies emergency attach from the attach request, and performs cleanup of existing normal bearers and generation of emergency bearers by means of authentication and authorization, and bearer context setup.

As a result, at operation <NUM>, an IMS call is set up between the UE <NUM> and the core network.

<FIG> illustrates another procedure for signal exchange according to the second example.

Specifically, <FIG> depicts a scheme in which the user equipment explicitly makes a normal bearer cleanup request.

Referring to <FIG>, a UE <NUM> may exchange signals with a network composed of the MME <NUM>, S-GW <NUM> and P-GW <NUM>. The UE <NUM> may exchange signals with the network via a base station (ENB).

If it is not possible to accommodate the number of bearers to be used for the emergency service owing to the number of simultaneously active bearers, at operation <NUM>, the UE <NUM> sends a request for releasing a normal bearer or normal PDN connection to the core network. Here, this request may be sent to the MME <NUM> through a bearer resource modification request or PDN disconnection request.

Upon reception of the request, at operation <NUM>, the MME <NUM> forwards the received request to the S-GW <NUM> through a bearer resource command or a delete session request.

Upon reception of the request, at operation <NUM>, the S-GW <NUM> forwards the received request to the P-GW <NUM> through a bearer resource command or a delete session request.

At operations <NUM> to <NUM>, a response to the request is sent by the P-GW <NUM> via the S-GW <NUM> and the MME <NUM> to the UE <NUM>.

As a result, at operation <NUM>, the UE <NUM> may be detached.

At operation <NUM>, the UE <NUM> sends an Attach request or PDN connectivity request to the MME <NUM>. This request may include type information indicating "emergency". At operation <NUM>, an emergency PDN connectivity request may be sent. In the event that all bearers have been released, as the UE <NUM> is detached, an emergency attach request may be sent.

At operation <NUM>, at least one of the emergency attach procedure and the emergency PDN connection procedure may be performed. At operation <NUM>, an IMS call is set up.

Meanwhile, in another embodiment of the present disclosure, for an emergency service, the UE <NUM> may locally deactivate existing bearers and notify the core network of this deactivation through a TAU procedure. More specifically, in response to a user request for an emergency service, when some or all of existing bearers are to be deactivated, the UE <NUM> selects bearers to be deactivated and sends a TAU request message containing information on the remaining active EPS bearers (except for the selected bearers) to the core network (active bits of the EPS bearer context status are set in the TAU request message). The UE <NUM> may also send a TAU request message containing bearer information (bearers to be deactivated are marked as inactive and bearers to be kept are marked as active) to the core network. Here, the UE <NUM> may notify the core network of the emergency service request by setting the EPS update type of the TAU request. The UE <NUM> may notify the core network of the emergency service request by using an additional update type of the TAU request. The UE <NUM> may also notify the core network of the emergency service request by using a separate emergency indicator of the TAU request. In addition, the UE <NUM> may notify the core network of S1/S5 setup for the following emergency service by setting the active flag of the TAU request.

Thereby, the MME <NUM> may be aware that the UE <NUM> has changed the bearer context for the emergency service. The MME <NUM> compares the pre-stored EPS bearer context status with the EPS bearer context status in the TAU request received from the UE <NUM> and may perform bearer cleanup if an EPS bearer to be deactivated is present.

When the UE <NUM> has sent a TAU request for an emergency service, to allow the UE <NUM> to promptly send a subsequent emergency service request (PDN connectivity request), the MME <NUM> may send a TAU accept response to the UE <NUM> before completion of bearer cleanup.

Upon reception of a TAU accept response, the UE <NUM> maybe aware of completion of requested bearer context status update, and may perform a subsequent procedure for the emergency service.

As another example, when bearer cleanup for an emergency service is needed during idle mode, the following scheme may be applied.

If some or all of existing bearers are to be deactivated for the emergency service, the UE <NUM> selects bearers to be deactivated and sends a TAU request containing information on the remaining active EPS bearers (except for the selected bearers) to the core network (active bits of the EPS bearer context status are set in the TAU request message). The UE <NUM> may also send a TAU request message containing bearer information (bearers to be deactivated are marked as inactive and bearers to be kept are marked as active) to the core network. To send a TAU request in idle mode, the UE <NUM> has to establish an RRC connection with the ENB. The UE <NUM> may send an RRC connection setup request whose establishment cause is set to "emergency".

The ENB forwards the TAU request message contained in an RRC message received from the UE <NUM> through S1-AP Initial UE message. When the RRC establishment cause is set to "emergency", the ENB may forward this together with the TAU request message.

Upon reception of the TAU request message with RRC establishment cause set to "emergency", the MME <NUM> may be aware that the UE <NUM> has sent the TAU request for an emergency service. Thereafter, subsequent operations may be processed as described before.

In the above two examples, the UE <NUM> is depicted as notifying the network of information on locally deactivated bearers using a TAU message. The same procedure may be applied to <NUM>/<NUM> networks using a Routing Area Update (RAU) message. Alternatively, the UE <NUM> may send an Extended Service Request (ESR) message having bearer status information instead of a TAU message having bearer status information.

The schemes described above may be readily applied without significant modification to existing systems and may be further enhanced so that requested emergency services can be provided to users as rapidly as possible.

Specifically, <FIG> depicts a signal exchange scheme in which cleanup of existing bearers and creation of new emergency bearers are simultaneously performed.

Referring to <FIG>, a UE <NUM> may exchange signals with a network composed of the ENB <NUM>, MME <NUM>, S-GW <NUM> and P-GW <NUM>.

If there is no need to deactivate some or all of the currently active bearers, the UE <NUM> may exchange signals with theMME <NUM> to establish a call for the emergency service.

If some or all of the currently active bearers are to be deactivated to provide the emergency service for the emergency call from the user, at operation <NUM>, the UE <NUM> selects bearers to be deactivated and sends a PDN connectivity request message containing information on the remaining active EPS bearers (except for the selected bearers) to the MME <NUM> (active bits of the EPS bearer context status are set in the PDN connectivity request message). The UE <NUM> may also send a PDN connectivity request message containing bearer information (bearers to be deactivated are marked as inactive and bearers to be kept are marked as active) to the MME <NUM>. The UE <NUM> may select bearers to be removed according to a criteria based on ARP, QCI, default/dedicated bearer (a dedicated bearer is removed), or inactivity duration.

Thereby, at operation <NUM>, the MME <NUM> may be aware that the UE <NUM> has changed the bearer context for the emergency service. The MME <NUM> compares the pre-stored EPS bearer context status with the EPS bearer context status in the PDN connectivity request received from the UE <NUM> and may perform bearer cleanup if an EPS bearer to be deactivated is present. The MME <NUM> may also perform bearer cleanup on the basis of information received at operation <NUM>. In addition, the MME <NUM> may perform a PDN connection creation procedure for the emergency service.

At operation <NUM>, the MME <NUM> sends a Create Session Request to the S-GW <NUM>. This Create Session Request may contain IDs of bearers to be removed.

At operation <NUM>, the S-GW <NUM> forwards the Create Session Request received at operation <NUM> to the P-GW <NUM>.

At operations <NUM> to <NUM>, each node sends or forwards a response message. At operation <NUM>, the ENB <NUM> may send an RRC connection Reconfiguration to the UE <NUM>. This RRC connection Reconfiguration may contain a DBR list. At operation <NUM>, an IMS call is set up between the UE <NUM> and core network.

Specifically, in <FIG>, a UE <NUM> requests the network to clean up existing normal bearers and to create bearers for an emergency service.

Referring to <FIG>, the UE <NUM> may exchange signals with a network composed of the ENB <NUM>, MME <NUM>, S-GW <NUM> and P-GW <NUM>.

Operation <NUM> and operation <NUM> are identical respectively to operation <NUM> and operation <NUM> in <FIG>.

If it is not possible to accommodate the number of bearers to be used for the emergency call placed by the user owing to the number of simultaneously active bearers, at operation <NUM>, the UE <NUM> sends an Emergency PDN connectivity request containing a cleanup indicator to existing bearers. This request may also include information on the number of bearers simultaneously supportable by the UE <NUM>.

At operation <NUM>, in the case wherein the maximum number of simultaneously activatable bearers in the UE <NUM> is known to the core network in advance when the UE <NUM> has issued an emergency service request, the MME <NUM> may autonomously perform bearer cleanup. In the case wherein the number of supportable bearers in the UE <NUM> is not known to the core network when the UE <NUM> has issued a bearer cleanup request, the MME <NUM> may simply remove all normal bearers.

The MME <NUM> may be aware of the maximum number of simultaneously supportable bearers in the UE <NUM> according to user subscription information. The context table in the UE <NUM> may have a mapping to the maximum number of supportable bearers based on ISMI, or the maximum number of active bearers may be known according to the model of the UE <NUM> based on IMEISV. In this case, the MME <NUM> may have to store mappings for UE models based on IMEISV and the maximum number of active bearers in each UE model.

To notify the MME <NUM> of such information, the operator may update UE information in the HSS or may set information on the IMEISV-based model of the UE <NUM> and the maximum number of bearers corresponding to the model in the MME <NUM> through O&M configuration or the like.

Upon reception of the emergency PDN connectivity request from the UE <NUM>, the MME <NUM> may determine that some or all of normal bearers are to be removed on the basis of information on the UE <NUM> and the maximum number of supportable bearers. When only some of normal bearers are to be removed, selection of bearers to be removed may be performed according to a criteria based on ARP, QCI, default/dedicated bearer (a dedicated bearer is removed), or inactivity duration.

At operations <NUM> and <NUM>, the core network removes corresponding active normal bearers (bearer cleanup from the S-GW <NUM> to the P-GW <NUM>) and creates emergency bearers/sessions. Here, cleanup of existing bearers and creation of new emergency bearers may be simultaneously performed or separately performed in sequence. For simultaneous performance, a list of bearers to be removed or a cleanup indicator indicating removal of all normal bearers maybe inserted in the Create session request message for emergency bearer creation.

The MME <NUM> notifies the ENB <NUM> of information on removed bearers and newly created bearers (bearer ID, bearer QoS, S5 TEID or the like). The ENB <NUM> updates data radio bearers related to the UE <NUM> accordingly.

When IDs of bearers to be removed are included in the emergency PDN connectivity request, the core network may remove the indicated active normal bearers (bearer cleanup from the S-GW <NUM> to the P-GW <NUM>) and perform emergency bearer/session creation.

Here, cleanup of existing bearers and creation of new emergency bearers may be simultaneously performed or separately performed in sequence. For simultaneous performance, a list of bearers to be removed or a cleanup indicator indicating removal of all normal bearers may be inserted in the Create session request message for emergency bearer creation.

The MME <NUM> notifies the ENB <NUM> of information on removed bearers and newly created bearers (bearer ID, bearer QoS, S5 TEID or the like). The ENB <NUM> updates data radio bearers related to the UE <NUM> accordingly. Finally, this update is known to the UE <NUM>.

In another example of the present disclosure, merging of the EMM process and the ESM process is proposed. That is, a TAU/RAU request message or ESR message containing an ESM message container is transmitted. Here, an ESM request message (e.g. PDN connectivity request) created by the UE <NUM> may be contained in the ESM message container.

More specifically, upon emergency service initiation, the UE <NUM> sends information on locally deactivated bearers through a TAU/RAU request message or an ESR message, whose ESM message container includes a PDN connectivity request. In other words, the UE <NUM> inserts information on locally deactivated bearers or information on the remaining active bearers after deactivation in the EPS bearer context status IE of a TAU request, RAU request or ESR message, inserts a PDN connectivity request for the emergency service in the ESM message container thereof, and sends the TAU request, RAU request or ESR message to the MME <NUM>. The MME <NUM> may not only perform bearer cleanup for the UE <NUM> according to the above examples but also handle a PDN connection creation request using the PDN connectivity request contained in the ESM message container. In the above-described schemes for emergency call provisioning according to the second example, information elements contained in each signal may be used interchangeably.

When a core network node (e.g. MME or SGSN) becomes congested owing to heavy signaling load, the core network node may redirect user equipments being served so that the user equipments can be served by another core network node.

This process may be realized through a procedure performed by a base station node to newly select a core network node for a user equipment and through a procedure to register UE information in the core network node. However, if the previous core network node in congestion is reselected by the base station node performing the core network node selection procedure, congestion may be not resolved. In addition, when the core network node serving a user equipment is changed after a new core network node is selected by the base station node, it is necessary to register UE information in the new core network node. Here, to obtain information on the user equipment stored in the previous core network node, making an information request to the previous core network node may exacerbate conditions of the previous core network node already in congestion.

In this embodiment, a core network node in congestion may notify a user equipment of difficulty of service provisioning owing to congestion through NAS layer information. Upon reception of such notification, the user equipment does not provide information enabling identification of the previous core network node (e.g. S-TMSI, GUTI, GUMMEI, or P-TMSI) to the lower layer (AS layer) during reconfiguration of core network registration. Without information on the previous core network node, the AS layer of the user equipment cannot provide information thereon when an RRC connection is established with the base station, causing the base station to select a new core network node for the user equipment. A NAS request message (e.g. attach request) from the user equipment is delivered to the newly selected core network node via the base station. Here, to prevent exacerbation of congestion that may be caused by the new core network node trying to obtain UE context information from the previous core network node, the user equipment may provide the new core network node with information (or indicator) that directs the new core network node to directly communicate with the HSS to thereby configure UE context information.

<FIG> illustrates a procedure for signal exchange according to the embodiment.

Referring to <FIG>, a UE <NUM> may exchange signals with the MME/SGSN <NUM> or <NUM> via the RAN <NUM>. Here, in terms of congestion, the MME/SGSN <NUM> or <NUM> may be referred to as old MME/SGSN <NUM> (to which a connection has been made) or referred to as new MME/SGSN <NUM> (to which a connection will be made). However, it should be evident that change of the MME/SGSN may also be triggered by a cause other than congestion.

At operation <NUM>, congestion is generated in the old MME/SGSN <NUM>. Congestion may be caused by an increase in traffic, operational failure of some devices or the like.

As shown, at operation <NUM>, the UE <NUM> sends a NAS request message (e.g. TAU request or attach request) to a core network node in congestion (referred to as old core network node). At operation <NUM>, the old core network node sends an NAS response or reject message (e.g. TAU reject or attach reject) together with information indicating rejection of the request owing to congestion or indicating necessity of UE re-registration as loaded state to the UE <NUM>. Here, the S1-AP message (Downlink NAS Transport), which encapsulates the NAS message and is sent to the RAN <NUM> (base station), may further include information indicating necessity of releasing an RRC connection between the UE <NUM> and RAN <NUM> after delivery of the NAS message (e.g. immediate release required indicator).

At operation <NUM>, the RAN <NUM> sends an RRC message (DLInformationTransfer), which contains the message received from the core network node, to the UE <NUM>. The RRC message may contain a congestion notification and timer information.

Upon reception of a request for immediate release of the RRC connection, at operation <NUM>, the RRC connection is immediately released after message delivery. The RRC connection is released because, as the RAN <NUM> reselects a core network node for the UE <NUM> during RRC connection setup, if an existing RRC connection is reused when the UE <NUM> makes a NAS request, the old core network node may be reused.

As a scheme to obtain similar effects, a timer value may be inserted in a NAS response/reject message sent by the core network node to the UE <NUM> or in an RRC message (DLInformationTransfer) sent by the RAN <NUM> to the UE <NUM>. This timer value acts as a protection interval needed by the RAN <NUM> to release an existing RRC connection. That is, when a timer value is received through a core network node or an RRC message, the UE <NUM> may make a NAS request after expiration of the corresponding timer.

Thereafter, at operation <NUM>, when a NAS request (Attach request) is made, the NAS layer of the UE <NUM> prevents delivery of information enabling identification of the old core network node (e.g. S-TMSI, GUTI, GUMMEI or P-TMSI) to the lower layer.

At operation <NUM>, RRC connection request/setup are performed. At operation <NUM>, during RRC connection setup, the AS layer of the UE <NUM> does not send information enabling identification of the old core network node (e.g. MME routing information) to the RAN <NUM>.

At operation <NUM>, the RAN <NUM> receives an RRC connection setup complete message. At operation <NUM>, as information enabling identification of the old core network node is not present, the RAN <NUM> selects a new core network node. At operation <NUM>, the RAN <NUM> forwards the contained NAS request message to the new core network node.

Upon reception of the NAS request message for the UE <NUM>, the new core network node has to perform a procedure for obtaining context information of the UE <NUM>. Here, the new core network node may send a request for context information of the UE <NUM> to the old core network node if necessary by use of an identifier (GUTI, oroldGUTI) inserted by the UE <NUM> in the NAS request message. However, when many such requests are concentrated in the old core network node in congestion, congestion may worsen. To solve this problem, <NUM>) when congestion arise, the old core network node may notify the new core network node of the congestion state through message exchange between core network nodes such as overload indication, or <NUM>) when the new core network node sends an identification request for context information, the old core network node may notify the new core network node of the congestion state through a response/rejection to the request. Upon reception of the notification, the new core network node may be aware that the old core network node is overloaded and may store the notification for later use. At operation <NUM>, the core network performs a procedure of identity request/response to obtain the IMSI of the UE <NUM>. At operation <NUM>, the core network receives the IMSI from the UE <NUM> and performs UE context setup and necessary registration using the received IMSI.

<FIG> illustrates another procedure for signal exchange according to the embodiment.

Referring to <FIG>, a UE <NUM> may exchange signals with the MME/SGSN <NUM> or <NUM> via the RAN <NUM>. Here, in terms of congestion, theMME/SGSN <NUM> or <NUM> maybe referred to as old MME/SGSN <NUM> (to which a connection has been made) or referred to as new MME/SGSN <NUM> (to which a connection will be made). However, it should be evident that change of the MME/SGSN may also be triggered by a cause other than congestion.

Operations <NUM> to <NUM> correspond respectively to operations <NUM> to <NUM> in <FIG>.

At operation <NUM>, the UE <NUM> generates a NAS request (attach request) containing an indication to overload of the old core network node or to preference for core network change at the NAS layer and sends the NAS request to the RAN <NUM> (base station). At operation <NUM>, the RAN <NUM> selects a new core network node (MME/SGSN <NUM>) and sends an Initial UEmessage to theMME/SGSN <NUM>. Here, the Initial UE message may contain an indication notifying re-attachment due to core network overload. Upon reception of the NAS request message for the UE <NUM>, at operation <NUM>, the new core network node has to perform a procedure for obtaining context information of the UE <NUM>. When cause information (overload of the old core network node or preference for core network change) is included, the new core network node may be aware that the old core network node is overloaded and may store the notification for later use. If necessary, the new core network node may perform a procedure of identity request/response to obtain the IMSI of the UE <NUM>. At operation <NUM>, the core network receives the IMSI from the UE <NUM> and performs UE context setup and necessary registration using the received IMSI.

The UE <NUM> generates a NAS request (attach request) containing IMSI as UE ID instead of GUTI or old GUTI at the NAS layer when the present NAS request is to be generated owing to overload of the old core network node or preference for core network change, and sends the NAS request. Thereby, the new core network node does not send a request for UE context information to the old core network node and may perform UE context setup for the UE <NUM> and necessary registration on the basis of the IMSI.

At operation <NUM>, the RAN <NUM> sends an Initial UE message containing the NAS request and IMSI of the UE <NUM>. At operation <NUM>, necessary registration is performed.

While the embodiments described in <FIG> are related to a case wherein the UE <NUM> explicitly sends a NAS request to a core network node, the embodiment described in <FIG> may also be applied to a case wherein the UE <NUM> does not explicitly send a NAS request. For example, upon determining that a core network node is overloaded, the UE <NUM> is notified of necessity of core network node reconfiguration via the RAN <NUM> and is registered through a new core network node using a procedure similar to those depicted in <FIG>. At operation <NUM>, the UE <NUM>, RAN <NUM> and old MME/SGSN <NUM> operate in connected mode.

At operation <NUM>, a core network node (old MME/SGSN <NUM>) detects overload. At operation <NUM>, the core network node sends a command message to the RAN <NUM>. Here, the command message contains information indicating necessity of connection release as to the UE <NUM> for load balancing.

Upon reception of the command message, at operation <NUM>, the RAN <NUM> sends an RRC connection release command indicating necessity of core network change for load balancing to the UE <NUM>. Operations after RRC connection release are similar to those after RRC connection release described in <FIG>, and a detailed description thereof is omitted.

The above description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the present disclosure as defined by the claims. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope of the present disclosure.

Claim 1:
A method performed by a base station (<NUM>) in a wireless communication system, the method comprising:
receiving (<NUM>), from a first core network entity (<NUM>, <NUM>), information indicating that the first core network entity (<NUM>, <NUM>) is unavailable;
transmitting (<NUM>) to a terminal (<NUM>), information indicating that the first core network entity is unavailable;
receiving (<NUM>, <NUM>), from the terminal (<NUM>), a first message for requesting a registration, wherein the first message does not include information for identifying a core network entity;
selecting (<NUM>) a second core network entity (<NUM>, <NUM>) as the first message does not include the information for identifying a core network entity; and
transmitting (<NUM>), to the second core network entity, a second message including the first message.