Patent Description:
Therefore, the <NUM> or pre-<NUM> communication system is also called a "Beyond <NUM> Network" or a "Post LTE System".

In the <NUM> system, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access(NOMA), and sparse code multiple access (SCMA) as an advanced access technology have also been developed.

The <NUM> system is considering supports for more various services as compared to the conventional <NUM> system. For example, the most representative service may include a ultrawide band mobile communication service (enhanced mobile broad band (eMBB)), a ultrahigh reliable/low latency communication service (ultra-reliable and low latency communication (URLLC)), a massive device-to-device communication service (massive machine type communication (mMTC)), and a next-generation broadcast service (evolved multimedia broadcast/multicast service (eMBMS)). A system providing the URLLC service may be referred to as a URLLC system, and a system providing the eMBB service may be referred to as an eMBB system. The terms "service" and "system" may be interchangeably used.

Among these services, the URLLC service that is a new service under consideration in the <NUM> system in contrast to the existing <NUM> system requires to meet ultrahigh reliability (e.g., packet error rate of about <NUM>-<NUM>) and low latency (e.g., about <NUM>. 5msec) conditions as compared to the other services. To meet these strict conditions required therefor, the URLLC service may need to apply a shorter transmission time interval (TTI) than the eMBB service, and various operating scheme employing the same are now under consideration.

Document from<NPL>) discloses SMF service context transfer procedures.

The invention is summarized in the attached independent claims. The dependent claims outline further embodiments.

The invention corresponds to the embodiment of <FIG>. Other embodiments are not encompassed by the wording of the claims but are considered as useful for understanding the invention.

<FIG>, discussed below, and the various examples used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure.

Hereinafter, the operation principle of the disclosure will be described in detail in conjunction with the accompanying drawings. In the following description of the disclosure, a detailed description of known functions or configurations incorporated herein will be omitted when it may make the subject matter of the disclosure rather unclear. The terms which will be described below are terms defined in consideration of the functions in the disclosure, and may be different according to users, intentions of the users, or customs. Therefore, the definitions of the terms should be made based on the contents throughout the specification.

In the following description, terms for identifying access nodes, terms referring to network entities, terms referring to messages, terms referring to interfaces between network entities, terms referring to various identification information, and the like are illustratively used for the sake of convenience. Therefore, the disclosure is not limited by the terms as used below, and other terms referring to subjects having equivalent technical meanings may be used.

In the following description, the disclosure uses terms and names defined in 3rd generation partnership project long term evolution (3GPP LTE) standards for the convenience of description. However, the disclosure is not limited by these terms and names, and may be applied in the same way to systems that conform other standards.

Meanwhile, in describing examples, a node/NF having functions of separating, storing, and retrieving UE information (UE context) processed/managed by an NF will be called a "context storage" that has a concept including an unstructured data storage function (UDSF) that is an NF for storing/sharing unstructured data and a context transfer storage function (CTSF) that is an NF for storing/transmitting context.

Meanwhile, in the disclosure, the term "service" will be used to refer to an "NF service" in which a specific communication device (or NF) processes a request by another communication device (or NF), and a "customer service" will be separately used in order to specifically indicate a service provided to an end-user.

A new system structure and protocol were required to support various services of <NUM> and then 3GPP decided to introduce a new technology called "service-based architecture (SBA)".

<FIG> illustrates a diagram of the structure of an SBA-based <NUM> system according to an example.

Referring to <FIG>, an access and mobility management function (AMF) <NUM> is a network function (NF) that manages access and mobility of a UE <NUM> in a wireless network. A session management function (SMF) <NUM> is an NF that manages a session for the UE <NUM>, and session information includes QoS information, charging information, and information on packet processing. A user plane function (UPF) <NUM> is an NF that processes user plane traffic and is controlled by the SMF <NUM>. Although not shown in <FIG>, the <NUM> system may include a UDSF, and the UDSF is an NF that stores unstructured data. Any type of data may be stored or retrieved at a request by the NF.

<FIG> illustrates a diagram of the separation structure of NFs and context according to an example.

Referring to <FIG>, in an example, data (UE context) in the NF is separated from the NF and stored in a separate context storage, and a set of NFs that may share and use the same is referred to as an "NF set". Depending on an implementation environment, a specific NF may be operated/managed in the form of an NF instance, and the subject matter of the disclosure may be applied to an environment of managing and operating any one of the NF and the NF instance. In addition, the NF may be replaced with an NF service in the case of the operation in units of NF services, instead of implementation/realization in units of NFs. Accordingly, the term "NF" in the disclosure may encompass an NF instance, an NF service, and an NF service instance. If multiple NF sets coexist, distinct identifiers or names may be assigned to the respective NF sets in order to distinguish therebetween, and even if NFs in the NF set operate by sharing context with each other, the respective NFs may be assigned with different identifiers/names for management/operation thereof.

<FIG> illustrates a diagram of an example of the operation of a <NUM> system including a terminal, a base station, and a core according to an example.

Referring to <FIG>, step <NUM> may be performed in the case where a requester <NUM> making a request to any NF <NUM> included in an NF set for a service is a radio access network (RAN) (base station), and a radio resource control (RRC) connection is established between a UE <NUM> and the RAN <NUM> in order to transmit and receive signaling/data using radio resources.

In step <NUM>, the requester <NUM> makes a request to the NF <NUM> for a specific NF service. If the requester is the RAN <NUM>, the target NF <NUM> may be an AMF. In this case, the requester <NUM> may specify and transmit a receiver <NUM> of the request. If the request is transmitted to the NF set without specifying a specific NF, any NF in the NF set may receive the request.

In step <NUM>, the receiving NF <NUM> performs an operation according to the NF service request. The receiving NF <NUM> identifies whether or not the requested NF service requires UE context that is pre-cached in the NF set, that is, in the NF or the context storage <NUM>. If information is pre-cached in the NF, the cached information may be directly used, so that steps <NUM> to <NUM> may be omitted.

If the UE context cached in the context storage <NUM> is required, the NF <NUM> makes a request to the context storage <NUM> for retrieving the context in step <NUM>. In this case, if the context storage <NUM> is a UDSF, a "Nudsf_UnstructuredDataManagement_Query service (request)" may be used for the context retrieval request, and the request message may include a data identifier for identifying data to be retrieved. If the NF <NUM> is aware of a correct data identifier, the identifier capable of identifying data may include a value corresponding thereto. Otherwise, the identifier may include an identifier of a specific UE. The identifier of a specific UE (subscriber) includes a subscription permanent ID (SUPI) (an IMSI or NAI type) or a unique temporary identifier in a specific NF set {pre-assigned as one of a <NUM>-globally unique temporary identifier (GUTI), an internet protocol (IP) address, a tunnel endpoint ID (TEID), a flow ID, an application/service ID, a charging ID, and the like}.

In step <NUM>, the context storage <NUM> searches for data to be retrieved according to the request by the NF <NUM> and transmits, to the NF <NUM>, a response thereto in step <NUM>. If the request is valid, that is, if the context storage <NUM> is able to retrieve valid context using the identifier included in the request message, the response message transmitted in step <NUM> includes the corresponding context. In this process, the context storage <NUM> may consider the identifier included in the request (a data identifier or a UE/subscriber identifier) and the type of the NF <NUM> making the request (a type such as AMF, SMF, etc.) in order to check the validity of the request by the NF <NUM> and find the context to be retrieved. In the case where the context storage <NUM> is a UDSF, the response corresponds to a response of "Nudsf_UnstructuredDataManagement_Query" service. If the request in step <NUM> is made using an identifier of a UE (subscriber), instead of using a specific data identifier, and if a specific data identifier is pre-assigned to the context storage <NUM>, the response transmitted in step <NUM> includes the data identifier. In addition, upon receiving the response, the NF <NUM> may store the data identifier, and may use the corresponding data identifier when making a request to the context storage <NUM> in the future. According to this, it is possible to reduce the time taken for the context storage <NUM> to search for the stored context using the UE (subscriber) identifier or to reduce the load on the context storage <NUM> to do so.

In step <NUM>, the procedure/transaction requested in step <NUM> is processed using the corresponding context. In the example, the procedure/transaction includes a processing operation in a specific NF, and further includes an operation of transmitting/receiving a message and requesting services by interworking with another NF according thereto.

In the case where the UE context is required to be updated or new UE context is required to be stored in the context storage <NUM> by a request, the NF <NUM> makes a request to the context storage <NUM> for storing/updating context in step <NUM>, and the request includes identifiers of the new context and data or identifiers of the context and data to be updated. If the context storage <NUM> is a UDSF, the corresponding operation may be performed using services "Nudsf_UnstructuredDataManagement_Create (storage)" and "Nudsf_UnstructuredDataManagement _Update (update)". In the case of update, if the NF <NUM> is explicitly aware of the data identifier or receives the same, the NF <NUM> may perform updating the UE context using the corresponding data identifier. In addition, in the case of "create", the NF <NUM> may transmit, to the context storage <NUM>, the UE (subscriber) identifier and the context to be stored.

In step <NUM>, the context storage <NUM> may store the context transmitted from the NF <NUM>, and if a new data identifier is required to be created(generated) (in the case of using a UE or subscriber identifier in step <NUM>), the context storage <NUM> may create a new data identifier, and may transmit the same to the NF <NUM> through a response in step <NUM>.

The NF <NUM> and other nodes <NUM> and <NUM> process the remaining procedures/transactions in step <NUM>. If a new temporary ID (one or more of a <NUM>-GUTI, a TEID, and an IP address) for a UE (subscriber) is assigned through the corresponding procedure/transaction, the ID is transmitted to the UE <NUM>, and the UE <NUM> stores the same for use in subsequent procedures.

The above example has described a method of grouping multiple NFs into an NF set and separating/sharing contexts. When performing a process of providing connectivity to a user through a <NUM> system, various types of temporary identifiers are assigned. Although the examples are described based on the following temporary identifiers, the subject matter of the disclosure may be applied to the case of assigning/managing any type of temporary identifier used in the communication system.

If the NF assigns a temporary identifier to a specific UE (subscriber), uniqueness must be assured according to a certain condition, and if the uniqueness is not satisfied, an error occurs, thereby degrading the quality of service or requiring an error recovery process. Unlike the system in which all the resources inside one NF are consumed, in the structure described in the above example, NFs in an NF set share context, and an NF serving a single UE (subscriber) may be changed at any time in the same set. In such a system, since the entire pool of temporary identifiers is also shared by the NFs, there may be a problem in that two NFs simultaneously assign one temporary identifier to two UEs (subscribers).

<FIG> illustrates a diagram of another example of the operation of a <NUM> system (a UE, a base station, and NFs) according to an example.

Referring to <FIG>, reference numeral <NUM> denotes an interworking node that may request/trigger NF services in a specific NF, and may be a UE, a RAN (base station), or another NF.

Reference numeral <NUM> represents an NF for providing a communication function, and includes an NF defined in the 3GPP standard and a network equipment similar thereto. If a specific NF is implemented/operated in the form of an instance, the NF may be replaced with an NF instance. The NF may be replaced with an NF service in the case of the operation in units of NF services, instead of implementation/realization in units of NFs.

A configuration server (conf. server) <NUM> is a server providing a function of managing/configuring communication equipments (a RAN, an NF, etc.), and is generally called an "element management system (EMS)" or an "operation and maintenance (OAM) system". A virtualized network function manager (VNFM)/orchestrator <NUM> is a system that configures/manages NFs in a virtualized system. In the disclosure, an example will be described on the assumption that two systems are separated, but the two systems may be integrated into one, and in this case, the exchange of messages between the two systems may be omitted, or may be processed through an internal procedure.

In step <NUM>, the NF <NUM> is initially installed or configured.

In step <NUM>, the VNFM/orchestrator <NUM> informs the configuration server <NUM> of the size of the NF (typically corresponding to the maximum capacity) (a value such as the number of concurrently processible subscribers or the number of sessions, a value indicating the relative capacity, or the like) and the size of the NF set (the number of NFs included in the NF set, the maximum capacity of the entire set, or the like).

In step <NUM>, the configuration server <NUM> may divide the entire pool of temporary identifiers shared by the NF set by the received size of the NF/NF set, thereby determining an available identifier to be used for each NF, and may transmit information assigned to each NF <NUM>. Available identifier information may be transmitted to the NF <NUM> according to the type thereof, and the configuration server <NUM> may transmit, to the NF <NUM>, a start value of the temporary identifier, a form of the total number or a range of the temporary identifiers (values indicating a start to an end), or a list of all assigned identifiers. When managing the temporary identifier, the configuration server <NUM> may reserve some sections in consideration of changes in the NW configuration (the size of an NF, the size of a set, etc.) in the future, and may perform initial assignment using the remaining sections.

In step <NUM>, the NF <NUM> stores a pool of temporary identifiers to be used by the NF <NUM> according to the received information.

The UE (or RAN or another NF) <NUM> makes a request to the NF <NUM> for a specific NF service in step <NUM>, and if a temporary identifier is required to be assigned to each UE (subscriber), the NF <NUM> may assign an identifier from the stored pool in step <NUM>. In step <NUM>, the NF <NUM> may respond to the UE (or RAN or another NF) <NUM>.

The above example may be utilized in the case where multiple NFs are included in an NF set. If the number of NFs in the NF set is dynamically changed (if a scaling-size changes due to malfunction or load), or if the size of each NF is changed, it is difficult to change the pool of identifiers to conform to the situation.

<FIG> illustrates a diagram of an example of effectively managing temporary identifiers even in the structure in which a <NUM> system is dynamically changed according to an example.

An ID management server <NUM> is a server providing a function of managing an identifier pool of all NFs. The ID management server <NUM> may be configured as a separate function (NF), or may be configured as a detailed function provided by the context server while being integrated with the context server described in the above example.

Step <NUM> means that the interworking node (UE/RAN/NF) <NUM> and the NF <NUM> are in the state capable of exchanging messages with each other and performing interworking operations.

In step <NUM>, the UE or interworking NF <NUM> makes a request to the NF <NUM> for an NF service. The request for an NF service by the interworking NF <NUM> may be made in the process of processing a service by a request of a UE, a request of a RAN, or the internal operation of an NF and a request by another NF.

In step <NUM>, the NF <NUM> processes the received transaction and determines whether new context needs to be created or a temporary identifier needs to be assigned.

In step <NUM>, the NF <NUM> may transmit, to the ID management server <NUM>, a request for assigning an ID or creating/updating context. In this case, the NF <NUM> may make a request to the ID management server <NUM> for a temporary identifier to be assigned to the UE (subscriber). The request message may include information on the type of temporary identifier to be used. The type information may include one or more of the above-described identifiers such as an M-TMSI, a <NUM>-GUTI, a GTP TEID, and an IP address. In addition, the NF <NUM> may make an explicit request to the ID management server <NUM> for whether or not to apply randomization when assigning the temporary identifier. If the ID management server <NUM> supports services of a UDSF, the request/response may be processed using the services described in the above example in <FIG>.

In step <NUM>, the ID management server <NUM> stores/updates the context if a request for processing context is received, and assigns the requested temporary identifier. If the requested temporary identifier requires randomization (e.g., in the case of the <NUM>-GUTI or the M-TMSI), or if separate randomization is explicitly requested, the ID management server <NUM> applies randomization when assigning the temporary identifier.

In step <NUM>, the ID management server <NUM> transmits, to the NF <NUM>, the assigned temporary identifier and, in the case where a request for processing context is received, a response to the context processing.

In step <NUM>, the NF <NUM> processes the remaining procedures/transactions using the assigned temporary identifier.

In step <NUM>, the assigned temporary identifier is transmitted to the interworking node (UE/base station or interworking NF) <NUM>, and the interworking node <NUM> receiving the temporary identifier stores the same for use in the subsequent procedures.

<FIG> illustrates a diagram of a method of dividing a pool of identifiers shared by an NF set into chunk units and assigning, managing, and collecting the same in units of chunks, instead of requesting and assigning temporary identifiers each time a transaction is processed according to another example.

The assignment method in units of chunks is effective because signaling between NFs for management of identifiers is able to be reduced and because collisions is able to be prevented while each NF freely assigns an identifier within a chunk.

An ID management server <NUM> is a server providing a function of managing an identifier pool of all NFs. The ID management server <NUM> may be configured as a separate function (NF), or may be configured as a detailed function provided by the context server while being integrated with the context server described in the above example. The ID management server <NUM> may be configured for each specific NF set, or may be configured to support multiple NF sets.

In step <NUM>, the NF <NUM> processes the received transaction and determines whether or not a temporary identifier needs to be assigned. Step <NUM> does not necessarily precede step <NUM>, and if assignment of the ID pool is required in an initiation process for processing a service request or in the general operation situation, the NF <NUM> may start from step <NUM>.

In step <NUM>, the NF <NUM> may transmit a request for ID assignment to the ID management server <NUM>. In this case, the NF <NUM> may make a request to the ID management server <NUM> for chuck assignment of a temporary identifier to be assigned to the UE (subscriber). The request message may include information on the type of temporary identifier to be used and a chunk size (that is, the number of IDs to be assigned). The type information may include one or more of the above-described identifiers such as an M-TMSI, a <NUM>-GUTI, a GTP TEID, and an IP address. In the case where the ID management server <NUM> is configured to simultaneously support multiple NF sets, the NF <NUM> may inform the ID management server <NUM> of the name or information of the NF set to which the NF <NUM> belongs using the request message. In addition, the NF <NUM> may make an explicit request to the ID management server <NUM> for whether or not to apply randomization when assigning the temporary identifier. If the ID management server <NUM> supports services of a UDSF, the request/response may be processed using the services described in the above example in <FIG>, and the assignment of the ID chunk may be implemented through an operation of creating specific context. Alternatively, a separate service for making an explicit request to the UDSF for ID assignment may be used.

In step <NUM>, the ID management server <NUM> assigns the requested temporary identifier. If the requested temporary identifier requires randomization (e.g., in the case of the <NUM>-GUTI or the M-TMSI), or if separate randomization is explicitly requested, the ID management server <NUM> applies randomization when assigning the temporary identifier. The ID management server <NUM> may accept the full size of the requested chunk, thereby assigning the temporary identifier, or may assign a smaller chunk. Information on the chunk includes an identifier of the chunk, which will be used for management (return or the like) in units of chunks in the future.

In step <NUM>, the ID management server <NUM> may transmit, to the NF <NUM>, the assigned temporary identifier chunk. The ID management server <NUM> may further transmit, to the NF <NUM>, information on success or failure and information on the chunk size.

Meanwhile, in another example, the operation of assigning/managing IDs in units of chunks may include an operation of exchanging information on the chunk in advance between the NF <NUM> and the ID management server <NUM> and transmitting only an identifier (or index) of the chunk in the actual operation such as assignment/return, as well as an operation of specifying and transmitting information on the identifiers included in the chunk (start values of identifiers, the number of identifiers, the range of identifiers, etc.) when performing chunk assignment as described in the above example.

<FIG> illustrates a diagram of a process in which a specific NF returns an assigned ID of which the use is terminated according to an example.

In step <NUM>, the UE or interworking NF <NUM> makes a request to the NF <NUM> for an NF service. The request for an NF service by the interworking NF <NUM> may be made in the process of processing a service by a request of a UE, a request of a RAN, or the internal operation of an NF and a request by another NF. In this case, the requested service is characterized in that the use of a specific temporary identifier is terminated, and the use of the identifiers, such as an M-TMSI (or <NUM>-GUTI) during a de-registration process, a GTP TEID and an IP address during a session release process, and the like, may also be terminated. Use of the temporary identifiers and deletion of the context may be performed after the lapse of a predetermined time, instead of immediately performing the same, depending on the implementation/configuration.

In step <NUM>, the NF <NUM> processes the received transaction and determines whether or not the temporary identifier needs to be returned. Step <NUM> does not necessarily precede step <NUM>, and if an ID is required to be returned when a timer expires or in the general operation situation, the NF <NUM> may start from step <NUM>.

In step <NUM>, the NF <NUM> may transmit a request for returning the ID to the ID management server <NUM>. In this case, the NF <NUM> may make a request to the ID management server <NUM> for chuck return of a temporary identifier to be assigned to the UE (subscriber). The request message may include a chunk identifier of the temporary identifier to be used. If management of IDs is performed simultaneously with management of context, the return of the temporary identifier assigned to a specific UE (subscriber) may be made simultaneously with deletion of the context for the specific UE (subscriber). If the ID management server <NUM> supports services of a UDSF, the request/response may be processed using the services described in the above example in <FIG>, and the assignment of the ID chunk may be implemented through an operation of deleting specific context. Alternatively, a separate service for making an explicit request to the UDSF for deletion of the ID may be used.

The ID management server <NUM> switches to the state in which the requested temporary identifier is no longer used in step <NUM>, and the ID management server <NUM> transmits, to the NF <NUM>, a response to the return in step <NUM>. If the ID is returned through processing of context, the ID management server <NUM> may transmit a response to deletion of context.

In step <NUM>, the NF <NUM> processes the remaining procedures/transactions.

In step <NUM>, a notification of deletion of the temporary identifier is transmitted to the node (the UE/base station or the interworking NF) <NUM> through the procedure of processing.

<FIG> illustrates a diagram of a method of selecting a target NF in consideration of the capacity of an NF receiving context when providing a service by exchanging context between context storages or NFs according to an example.

Referring to <FIG>, a context storage <NUM> represents a function of storing/transmitting data (UE context) created/managed by an NF in order to provide a communication service, and includes a CTSF, a UDSF, and the like. A network repository function (NRF)/service communication proxy (SCP) <NUM> is an NF that assists discovery, selection, and message routing for providing services between NFs using connection information and status information between NFs.

In step <NUM>, the context storage <NUM> may start a new service, or may change status.

In step <NUM>, the context storage <NUM> may newly register its own information (NF profile) in the NRF/SCP <NUM>, or may update the same (when the status/configuration is changed). In this case, the profile of the context storage <NUM> may include at least one of the maximum capacity that can be provided by the context storage, the current load status, and the throughput representing the number of contexts that can be processed (transmitted/received) during a unit time, the size of the context that can be stored by one transaction, and the like. In the case where the profile of the context storage <NUM> represents the maximum capacity, the load status, the throughput, and the size, the profile may be expressed using a relative value calculated based on the maximum value. Alternatively, the maximum capacity, the load status, the throughput, and the size may be expressed as absolute values. For example, the maximum capacity may be expressed as a combination of a specific context type (e.g., SM context) and the maximum number of acceptable contexts, and the number of contexts that can be processed at a time may be expressed as a combination of a specific context type and the maximum number of processible contexts. For the operation in step <NUM>, the context storage <NUM> may transmit, to the NRF/SCP <NUM>, a message such as an "NRRegister request" or an "NFUpdate request".

In step <NUM>, the NRF/SCP <NUM> may store the capacity, the status information, and the like (the NF profile) received from the context storage <NUM>.

In step <NUM>, if the NF <NUM> has insufficient information stored, another NF (SMF, AMF, etc.) <NUM> may transmit, to the NRF/SCP <NUM>, a discovery/selection request of the context storage in order to make a request for storing and transmitting context. The discovery/selection request may include information stating that the NF service to be requested is storage of context (context create, update, or push) or transmission thereof (context transfer) even though the explicit target to be discovered is the context storage (the CTSF or the UDSF). The request in step <NUM> may be an "NFDiscovery request message".

In step <NUM>, the NRF/SCP <NUM> may select the context storage (or a set of candidates) <NUM> according to the request, and may transmit, to the NF <NUM> that made a request, a response thereto in step <NUM>. In this case, the response may include necessary information (a combination of the identifier, access address, maximum capacity, current load status, throughput, simultaneous transmission capability, and the like of the context storage) among the NF profile of the context storage <NUM>, which is received and stored in step <NUM>, and the configuration and meaning of the detailed information may be the same as those described in step <NUM> above. The response transmitted in step <NUM> may be an "NFDiscovery response message".

In step <NUM>, the NF <NUM> may store the information received in step <NUM>, and if a response capable of specifying one context storage is received, the NF <NUM> may select the corresponding context storage. In addition, if candidates of multiple context storages to be a target are received, the NF <NUM> may select one of the candidates. In this case, when performing the selection, the NF <NUM> may select the context storage <NUM> capable of effectively providing services in consideration of the information (the maximum capacity, the load status, etc.) received in step <NUM>. Even when the NF <NUM> requests context-related services to the selected context storage <NUM>, the information received in step <NUM> may be considered. In particular, when the context storage <NUM> provides a limited amount of transmission, the NF <NUM> may create a request so as not to exceed the amount of transmission, and may create a request such that the size of the context (the number of contexts, the size of the context, etc.) included in the request does not exceed the limit.

In step <NUM>, the NF <NUM> transmits a service request to the context storage <NUM>. Thereafter, the NF <NUM> receives a response as a result of processing from the context storage <NUM>, and another procedure may be triggered, of which a detailed description will be omitted in the example. In step <NUM>, the NF <NUM> may transmit, to the context storage <NUM>, a CTSF service request message for the service request.

<FIG> illustrates a diagram of a method of managing context in an NF according to an example.

Referring to <FIG>, in step <NUM>, NFs <NUM> and <NUM> and a context storage NF <NUM> may perform registration, discovery, and selection processes to request/receive mutual service provision.

In step <NUM>, NF #<NUM> (<NUM>) may determine that an NF change operation is required.

In step <NUM>, NF #<NUM> (<NUM>) transmits context to the context storage (CTSF/UDSF) <NUM>, and transmits a service request for changing the NF. The service used in this case may be a service context push request, and the request message may include at least one of an identifier (context ID) capable of identifying the target context for context transfer and change of an NF, the type of context, an identifier of a target UE (subscriber), and an identifier of a target PDU session (if the context type is SM context). If the operation of the request to be transmitted to the context storage <NUM> includes changing the NF, as well as storing the context, the request message may further include an identifier of the NF to be changed. In this case, in order to select the NF to be changed, if backup NFs are preconfigured, NF #<NUM> (<NUM>) may select one of the backup NFs. Otherwise, NF #<NUM> (<NUM>) may select an NF from the same NF set. If the NF is not required to be changed, step <NUM> and steps subsequent thereto may not be performed.

In step <NUM>, the context storage <NUM> stores the context according to the request, and transmits, to the NF #<NUM> (<NUM>), a response thereto in step <NUM>. If a request for changing the NF is further requested in step <NUM>, the response in step <NUM> to the service request received in step <NUM> may be transmitted after receiving the result of changing the NF (step <NUM>). The response in step <NUM> may be a service context push response.

In the case where the context storage <NUM> receives a service request including the change of an NF in step <NUM>, the context storage <NUM> transmits the context to the target NF (NF #<NUM>) <NUM> to be changed in step <NUM>. The service used in this case may be a service context push request, and the request message may include at least one of an identifier (context ID) capable of identifying the target context for context transfer and change of the NF, the type of context, an identifier of a target UE (subscriber), and an identifier of a target PDU session (if the context type is SM context). In addition, the request message may include information indicating whether or not the context push service request is intended for context storage or whether or not the context push service request includes change of an NF.

The NF #<NUM> (<NUM>) may store the received context in step <NUM>, and may transmit a response as a result thereof to the context storage <NUM> in step <NUM>. In this case, the response message in step <NUM> may be a service context push response. Then, in step <NUM>, NF #<NUM> (<NUM>) performs other procedures/transactions according to reception of context and change of an NF. The order of steps <NUM>, <NUM>, and <NUM> may be changed with each other.

Table <NUM> below shows the type and structure of the context when the NF for transmitting and receiving context is an AMF in an example.

As shown in Table <NUM>, the AM context refers to the context created/managed by an AMF, and denotes data that is shared between AMFs, transmitted and received directly for changing an AMF, or transmitted through a context storage (CTSF). A data key for managing and browsing the AM context and indicating a specific AM context represents the identifier of a subscriber (SUPI).

<FIG> illustrates a diagram of a method for preventing malfunction and overload due to context transfer and change of an NF according to an example.

Referring to <FIG>, in step <NUM>, an NF <NUM> may perform a process of discovering/selecting another NF <NUM>.

In step <NUM>, NF #<NUM> (<NUM>) determines that context transfer to another NF (NF #<NUM>) <NUM> is required or that an NF is required to be changed along therewith, and in step <NUM>, NF #<NUM> (<NUM>) makes a request to a target NF (NF #<NUM>) <NUM> for a context push service. The message requesting the context push service may include at least one of an identifier (context ID) capable of identifying the target context for context transfer and change of an NF, the type of context, an identifier of a target UE (subscriber), and an identifier of a target PDU session (if the context type is SM context). In addition, the request message for a context push service may include information indicating whether or not the context push service request is intended for context storage or whether or not the context push service request includes changing an NF. The request message may be a service context push request.

In step <NUM>, NF #<NUM> (<NUM>) may store the received context, and if the NF is required to be changed, may perform other procedures/transactions according to change of the NF.

In step <NUM>, NF #<NUM> (<NUM>) transmits a result of the service request to NF #<NUM> (<NUM>), and the response message may include information on the current load status of the NF and information for processing the context, as well as the result. More specifically, the response message may include at least one of the maximum capacity that can be provided by NF #<NUM> (<NUM>), the current load status, and the throughput indicating the number of contexts that can be processed (transmitted/received) during a unit time, and the size of the context that can be stored through a single transaction. The response message may be a service context push response. In addition, NF #<NUM> (<NUM>) receiving the response may store the information included in the response, and may consider the information when selecting a target or requesting processing of context in the case where context transfer or change of an NF is required in the future.

<FIG> illustrates the detailed operation of an AMF according to an example. In this example, it is assumed that a pre-operation for transmitting the context of a UE to another SMF is triggered by a specific SMF.

Referring to <FIG>, in step <NUM>, an AMF receives, from an SMF (referred to as an "old SMF"), a message indicating that it is necessary to transmit the context for a specific UE and session to another SMF. This message may be "Nsmf_PDUSession_SMContextStatusNotify", and in order to receive the message, the AMF may perform subscription to the old SMF in advance in order to receive a notification of a change in status.

In step <NUM>, the AMF may select a target SMF (referred to as a "new SMF") using the information contained in the request message from the SMF. In addition, the AMF may transmit, to the new SMF, a request for receiving the context for the target UE and session from the old SMF. The message used in this case may be "Nsmf_PDUSession_CreateSMContext request".

In step <NUM>, the AMF may optionally start a timer for determining whether or not the session-related context transmission of the SMF and processing thereof are successful.

If a timer is set in step <NUM>, and if a response is not received from the new SMF until the set timer expires, the AMF may determine that the context processing procedure requested to the new SMF has failed in step <NUM>. Alternatively, if the AMF explicitly receives, from the new SMF, a message indicating that the context processing procedure has failed, the AMF may recognize that the procedure has failed. Alternatively, the AMF may recognize whether or not the procedure is successful through implementation inside the AMF or a method of receiving information from other NFs or OAM.

If it is determined that the context process requested to the new SMF has failed, the AMF may determine that a corresponding session has been released, and may perform a procedure of releasing a PDU session in step <NUM>. Alternatively, the AMF may inform the old SMF that the context processing has failed, so that the old SMF may perform subsequent procedures.

<FIG> illustrates the detailed operation of an AMF according to an embodiment. In this embodiment, it is assumed that a pre-operation for transmitting the context of a UE to another SMF is triggered by a specific SMF.

In step <NUM>, the AMF may select a target SMF (referred to as a "new SMF") using the information contained in the request message from the SMF. In addition, the AMF transmits, to the new SMF, a request for receiving the context for the target UE and session from the old SMF. The message used in this process may be "Nsmf_PDUSession_CreateSMContext request". Thereafter, the AMF starts a timer for determining whether or not the session-related context transmission of the SMF and processing thereof are successful.

In step <NUM>, before receiving the message indicating that the context processing procedure requested to the new SMF in step <NUM> is completed, the AMF receives a separate request for the corresponding UE (for example, a context transfer request received from another AMF during registration process or the service request or the like). In general, this may be a request stemming from the mobility of the UE, or may be a request caused by the occurrence of a service (transmission of a call or data) in the UE in an idle state.

In step <NUM>, the AMF determines whether or not the target UE and session include the currently changing SMF in processing the request received in step <NUM>. More specifically, if the operation to be processed for the UE is the service request, the AMF determines whether or not the currently changing SMF belongs to the SMF providing services to the PDU sessions to be processed for the UE. If the operation to be processed for the UE is the context transfer request requested by another AMF, the AMF determines whether or not the currently changing SMF belongs to the SMF managing the session of the UE. If the related SMF includes the currently changing SMF, the process proceeds to step <NUM>. Otherwise, the process proceeds to step <NUM>.

In step <NUM>, the AMF delays processing of the request received in step <NUM> until a message indicating that a context creation process is completed is received from the new SMF. That is, the AMF stores the request received in step <NUM> and waits. In this step, if the AMF receives, from the new SMF, a message informing that the context creation process is completed, the AMF updates the UE context (including the address of the SMF) according thereto and proceeds to step <NUM>. If the AMF sets a timer in step <NUM>, and if the AMF does not receive a response from the new SMF until the set timer expires, the AMF may determine that the context processing procedure requested to the new SMF has failed. Alternatively, if the AMF explicitly receives, from the new SMF, a message indicating that the context processing procedure has failed, the AMF may recognize that the procedure has failed. Alternatively, the AMF may recognize whether or not the procedure is successful through implementation inside the AMF or a method of receiving information from other NFs or OAM. If it is determined that the context process requested to the new SMF has failed, the AMF may determine that a corresponding session has been released, and may process the request received in step <NUM>. Alternatively, the AMF may inform the old SMF that the context processing has failed, so that the old SMF may perform subsequent procedures.

<FIG> illustrates a diagram of the configuration of a terminal according to the disclosure.

Referring to <FIG>, a terminal according to an example may include a transceiver <NUM> and a controller <NUM> that controls the overall operation of the terminal. In addition, the transceiver <NUM> may include a transmitter <NUM> and a receiver <NUM>.

The transceiver <NUM> may transmit and receive signals to and from other network entities.

The controller <NUM> may perform control such that the terminal performs any one of the operations described in the above examples. Meanwhile, the controller <NUM> and the transceiver <NUM> are not necessarily implemented as separate modules, and may be implemented as a single component in the form of a single chip. In addition, the controller <NUM> and the transceiver <NUM> may be electrically connected. In addition, for example, the controller <NUM> may be a circuit, an application-specific circuit, or at least one processor. Further, the operations of the terminal may be realized by providing a memory device storing corresponding program code to any component inside the terminal.

<FIG> illustrates a diagram of the configuration of a network entity according to the disclosure.

The network entity of the disclosure encompass a network function according to the implementation of a system.

Referring to <FIG>, a network entity according to an example may include a transceiver <NUM> and a controller <NUM> that controls the overall operation of the network entity. In addition, the transceiver <NUM> may include a transmitter <NUM> and a receiver <NUM>.

The controller <NUM> may perform control such that the network entity performs any one of the operations described in the above examples. Meanwhile, the controller <NUM> and the transceiver <NUM> are not necessarily implemented as separate modules, and may be implemented as a single component in the form of a single chip. In addition, the controller <NUM> and the transceiver <NUM> may be electrically connected. In addition, for example, the controller <NUM> may be a circuit, an application-specific circuit, or at least one processor. Further, the operations of the network entity may be realized by providing a memory device storing corresponding program code to any component inside the network entity.

The network entity may be any one of a base station (RAN), an AMF, an SMF, a UPF, an NF, an NEF, an NRF, a CF, an NSSF, a UDM, an AF, an AUSF, an SCP, a UDSF, a context storage, OAM, an EMS, a configuration server, and an ID management server.

It should be noted that the configuration diagrams, the diagrams illustrating examples of a method of transmitting control/data signals, the diagrams illustrating examples of operation procedures, and the like illustrated in <FIG> are not intended to limit the scope of the disclosure. That is, the components, entities, or operation steps described in <FIG> should not be interpreted as essential elements for the implementation of the disclosure, and the disclosure can be implemented using only some of the elements without impairing the subject matter of the disclosure.

The above-described operations of the base station or the terminal may be realized by providing a memory device storing corresponding program code to any component inside the base station or the terminal device. That is, the controller of the base station or the terminal device may read out and execute program code stored in the memory device using a processor or a central processing unit (CPU), thereby performing the above-described operations.

The various components and modules of the entity, the base station, or the terminal described herein may be operated using hardware circuits, for example, complementary metal oxide semiconductor-based logic circuits, firmware, and hardware circuits such as a combination of software and/or hardware and firmware and/or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using transistors, logic gates, and electrical circuits such as customized semiconductors.

Although the present disclosure has been described with various examples, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims. terminal described herein may be operated using hardware circuits, for example, complementary metal oxide semiconductor-based logic circuits, firmware, and hardware circuits such as a combination of software and/or hardware and firmware and/or software embedded in a machine-readable medium. For example, various electrical structures and methods may be implemented using transistors, logic gates, and electrical circuits such as customized semiconductors.

Claim 1:
A method performed by an access and mobility management function, AMF, entity in a communication system, the method comprising:
receiving (<NUM>), from a first session management function, SMF, a first message including information indicating that a transfer of a session management, SM, context to a second SMF is requested;
transmitting (<NUM>), to the second SMF, a second message for requesting the second SMF to receive the SM context from the first SMF;
starting a timer upon transmitting the second message; and
receiving, from the second SMF, a third message as a response to the second message before expiring the timer,
wherein the method further comprises:
receiving, from another AMF, a user equipment, UE, context transfer request due to terminal mobility, before receiving the third message; and
delaying (<NUM>) a processing of the UE context transfer request until receiving the third message.