Method and apparatus for performing header compression in a wireless system

Abstract

According to an embodiment of the present disclosure, a method performed by a user equipment (UE) in a wireless communication system is provided. The method may include: identifying an inter-system change from a first mode to a second mode; converting a data session established in the first mode from the first mode to the second mode; determining whether the UE and the network entity in the second mode support header compression; and initiating a process for negotiating a header compression configuration in the converted data session based on the result of the identification, wherein the first mode is one of the N1 mode and the S1 mode, and the second mode is the other of the N1 mode and the S1 mode.

Description

Technical Field

[0001] The present disclosure relates to methods, devices and systems for providing multi-mode interworking of data sessions in a network. More specifically, the present disclosure relates to interworking between a fifth generation system (5GS) and an evolved packet switching system (EPS) for protocol data unit (PDU) sessions using header compression in a third generation partnership project 5G (3GPP5G). Background Art

[0002] In order to meet the increased demand for wireless data traffic since the deployment of the fourth generation (4G) communication system, efforts have been made to develop an improved fifth generation (5G) or pre-5G communication system. 5G or pre-5G communication systems are also referred to as "beyond 4G networks" or "post-Long Term Evolution (LTE) systems". 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands (e.g., 60 GHz bands) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed for 5G communication systems. In addition, in 5G communication systems, development of system network improvements is underway based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference elimination, etc. In 5G systems, hybrid frequency shift keying (FSK), Fairchild quadrature amplitude modulation (FQAM) and sliding window superposition coding (SWSC) have been developed as advanced coded modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0003] The Internet, a human-centered connected network in which humans generate and consume information, is now developing toward the Internet of Things (IoT), in which distributed entities (such as things) exchange and process information without human intervention. The Internet of Everything (IoE), which combines IoT technology and big data processing technology by connecting to cloud servers, has emerged. As technical elements required for the realization of IoT, such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology", sensor networks, machine-to-machine (M2M) communication, machine-type communication (MTC), etc. have been studied recently. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination between existing information technology (IT) and various industrial applications, IoT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, MTC, and M2M communications can be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN, which is the above-mentioned big data processing technology, can also be considered an example of the fusion between 5G technology and IoT technology.

[0005] As described above, according to the development of wireless communication systems, various services can be provided, and thus a method for easily providing such services is required. Summary of the invention

[0006] Technical Solutions

[0007] According to an embodiment of the present disclosure, a method performed by a user equipment (UE) in a wireless communication system is provided. The method may include: identifying an inter-system change from a first mode to a second mode; converting a data session established in the first mode from the first mode to the second mode; determining whether the UE and the network entity in the second mode support header compression; and initiating a process for negotiating a header compression configuration in the converted data session based on the result of the identification, wherein the first mode is one of the N1 mode and the S1 mode, and the second mode is the other of the N1 mode and the S1 mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description in conjunction with the accompanying drawings, in which:

[0009] Figure 1A block diagram showing an exemplary network entity according to an embodiment of the present disclosure is shown;

[0010] Figure 2 A block diagram of a UE according to an embodiment of the present disclosure is shown; and

[0011] Figure 3 A block diagram of a core network entity according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0012] According to an embodiment of the present disclosure, a method performed by a user equipment (UE) in a wireless communication system is provided. The method may include: identifying an inter-system change from a first mode to a second mode; converting a data session established in the first mode from the first mode to the second mode; determining whether the UE and the network entity in the second mode support header compression; and initiating a process for negotiating a header compression configuration in the converted data session based on the result of the identification, wherein the first mode is one of the N1 mode and the S1 mode, and the second mode is the other of the N1 mode and the S1 mode.

[0013] In an embodiment of the present disclosure, the method may include sending a first message including first information related to whether the UE supports header compression to a network entity, receiving a second message including second information related to whether the network entity supports header compression from the network entity, and determining whether the UE and the network entity support header compression based on the first information and the second information.

[0014] In an embodiment of the present disclosure, the first message may include a capability information element (IE), and the first information is indicated by a bit included in the capability IE, and when header compression is supported, the bit may indicate a value of 1, and when header compression is not supported, the bit indicates a value of 0.

[0015] In an embodiment of the present disclosure, the second message may include a network feature support information element (IE), and the second information is indicated by a bit included in the network feature support IE, and when header compression is supported, the bit may indicate a value of 1, and when header compression is not supported, the bit indicates a value of 0.

[0016] In an embodiment of the present disclosure, the method may include initiating a process for negotiating a header compression configuration in a converted data session when the UE operates in a single registration mode and supports the N26 interface.

[0017] In an embodiment of the present disclosure, when the first mode is N1 mode and the second mode is S1 mode, the header compression may be IP header compression. In an embodiment of the present disclosure, when the first mode is S1 mode and the second mode is N1 mode, the header compression is one of IP header compression and Ethernet header compression.

[0018] According to an embodiment of the present disclosure, a method performed by a network entity communicating with a user equipment (UE) in a wireless communication system is provided. The method may include: identifying an inter-system change from a first mode to a second mode; converting a data session established in the first mode from the first mode to the second mode; determining whether the UE and the network entity in the second mode support header compression; and initiating a process for negotiating a header compression configuration in the converted data session based on the result of the identification, wherein the first mode is one of the N1 mode and the S1 mode, and the second mode is the other of the N1 mode and the S1 mode.

[0019] In an embodiment of the present disclosure, the method may include sending a first message including first information related to whether the UE supports header compression to a network entity, receiving a second message including second information related to whether the network entity supports header compression from the network entity, and determining whether the UE and the network entity support header compression based on the first information and the second information.

[0020] In an embodiment of the present disclosure, the first message may include a capability information element (IE), and the first information is indicated by a bit included in the capability IE, and when header compression is supported, the bit may indicate a value of 1, and when header compression is not supported, the bit indicates a value of 0.

[0021] In an embodiment of the present disclosure, the second message may include a network feature support information element (IE), and the second information is indicated by a bit included in the network feature support IE, and when header compression is supported, the bit may indicate a value of 1, and when header compression is not supported, the bit indicates a value of 0.

[0022] In an embodiment of the present disclosure, the method may include initiating a process for negotiating a header compression configuration in a converted data session when the UE operates in a single registration mode and supports the N26 interface.

[0023] In an embodiment of the present disclosure, when the first mode is N1 mode and the second mode is S1 mode, the header compression may be IP header compression. In an embodiment of the present disclosure, when the first mode is S1 mode and the second mode is N1 mode, the header compression is one of IP header compression and Ethernet header compression.

[0024] In an embodiment of the present disclosure, a user equipment (UE) in a wireless communication system is provided. The UE may include a transceiver and at least one processor, the processor being configured to: identify an inter-system change from a first mode to a second mode, convert a data session established in the first mode from the first mode to the second mode, determine whether the UE and a network entity in the second mode support header compression, and based on a result of the determination, initiate a process for negotiating a header compression configuration in the converted data session, wherein the first mode is one of the N1 mode and the S1 mode, and the second mode is the other of the N1 mode and the S1 mode.

[0025] Before proceeding to the following detailed description, it may be helpful to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprising," and their derivatives, mean inclusion without limitation; the term "or" is inclusive, meaning and / or; the phrases "associated with" and "associated with," and their derivatives, may mean including, included, interconnected with, containing, contained within, connected to or connected with, coupled to or coupled with, communicable with, cooperating with, interlaced, juxtaposed, proximate, combined to or combined with, having, having characteristics, and the like; the term "controller" refers to any device, system, or part thereof that controls at least one operation, such device being implemented in hardware, firmware, or software, or some combination of at least two thereof. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely.

[0026] In addition, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed by a computer-readable program code and contained in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, related data or a part thereof suitable for implementation with a suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as a read-only memory (ROM), a random access memory (RAM), a hard drive, a compact disc (CD), a digital video disc (DVD) or any other type of memory. "Non-transient" computer-readable media do not include wired, wireless, optical or other communication links that transmit instantaneous electrical signals or other signals. Non-transient computer-readable media include media that can permanently store data and media that can store data and rewrite data later, such as rewritable optical discs or erasable storage devices.

[0027] Definitions for certain words and phrases are provided throughout this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

[0028] Discussed below Figures 1 to 3 The various embodiments used to describe the principles of the present disclosure in this patent document are merely exemplary and should not be interpreted in any way as limiting the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can be implemented in any appropriately arranged system or device.

[0029] Throughout the disclosure, the expression "at least one of a, b, and c" means only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof. Throughout the specification, a layer (or layer arrangement) may also be referred to as an entity. Hereinafter, the operating principle of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description, well-known functions or configurations are not described in detail because they would obscure the present disclosure with unnecessary details. The terms used in the specification are defined in consideration of the functions used in the present disclosure and may change according to the intention or common methods of the user or operator. Therefore, the definition of the terms is to be understood based on the entire description of this specification.

[0030] For the same reason, in the accompanying drawings, some elements may be exaggerated, omitted or roughly shown. In addition, the size of each element does not completely correspond to the actual size of each element. In each of the accompanying drawings, the same or corresponding elements are represented by the same reference numerals.

[0031] By referring to the following detailed description of the embodiments and drawings of the present disclosure, the advantages and features of the present disclosure and the methods for realizing the same can be more easily understood. However, the present disclosure can be implemented in many different forms and should not be interpreted as being limited to the embodiments set forth herein; on the contrary, these embodiments of the present disclosure are provided to make the present disclosure thorough and complete, and to fully convey the concept of the present disclosure to those of ordinary skill in the art. Therefore, the scope of the present disclosure is defined by the appended claims. Throughout the specification, the same reference numerals refer to the same elements. It will be understood that the combination of the blocks in the flow chart or the flow chart can be performed by computer program instructions. Because these computer program instructions can be loaded into a processor of a general-purpose computer, a special-purpose computer, or another programmable data processing device, the instructions executed by the processor of the computer or another programmable data processing device create units for performing the functions described in the (multiple) flow chart blocks.

[0032] Computer program instructions may be stored in a computer-usable or computer-readable memory that can direct a computer or another programmable data processing device to implement functions in a specific manner, so that the instructions stored in the computer-usable or computer-readable memory can also produce an article of manufacture containing instruction units for performing the functions described in the (multiple) flowchart blocks. The computer program instructions may also be loaded into a computer or another programmable data processing device, so that when a series of operations are performed in the computer or another programmable data processing device, the instructions for operating the computer or another programmable data processing device by generating a computer-implemented process can provide operations for performing the functions described in the (multiple) flowchart blocks.

[0033] In addition, each box can represent a module, a fragment or a part of a code including one or more executable instructions for performing (multiple) specified logical functions. It should also be noted that in some alternative embodiments, the functions mentioned in the box may not appear in order. For example, depending on the function corresponding thereto, two consecutive boxes may also be executed simultaneously or in reverse order.

[0034] As used herein, the term "unit" represents a software element or a hardware element, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and performs a specific function. However, the term "unit" is not limited to software or hardware. A "unit" can be formed to be located in an addressable storage medium, or can be formed to operate one or more processors. Therefore, for example, the term "unit" can include an element (e.g., a software element, an object-oriented software element, a class element, and a task element), a process, a function, an attribute, a process, a subroutine, a program code segment, a driver, a firmware, a microcode, a circuit, data, a database, a data structure, a table, an array, or a variable.

[0035] The functions provided by the elements and "units" may be combined into a smaller number of elements and "units", or may be separated into additional elements and "units". In addition, the elements and "units" may be implemented to reproduce one or more central processing units (CPUs) in a device or a secure multimedia card. In addition, in an embodiment of the present disclosure, a "unit" may include at least one processor. In the following description of the present disclosure, well-known functions or configurations are not described in detail because they would obscure the present disclosure with unnecessary details.

[0036] Hereinafter, for convenience of explanation, the present disclosure uses terms and names defined in the 3rd Generation Partnership Project Long Term Evolution (3GPP LTE) standard. However, the present disclosure is not limited to the terms and names and may also be applied to systems complying with other standards.

[0037] In the present disclosure, for the convenience of explanation, the evolved Node B (eNB) may be used interchangeably with the next generation Node B (gNB). That is, the base station (BS) described by the eNB may represent the gNB. In the following description, the term "base station" refers to an entity for allocating resources to a user equipment (UE), and may be used interchangeably with at least one of a gNode B, an eNode B, a Node B, a base station (BS), a radio access unit, a base station controller (BSC), or a node on a network. The term "terminal" may be used interchangeably with a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function. However, the present disclosure is not limited to the foregoing examples. Specifically, the present disclosure is applicable to the 3GPP New Radio (NR) (or fifth generation (5G)) mobile communication standard. In the following description, for the convenience of explanation, the term eNB may be used interchangeably with the term gNB. That is, a base station interpreted as an eNB may also indicate a gNB. The term UE may also represent a mobile phone, a NB-IoT device, a sensor, and other wireless communication devices.

[0038] Reference is made to the following documents: [1] 3GPP TS 24.301 v16.4.0; and [2] 3GPP TS 24.501 v16.4.1.

[0039] Various acronyms, abbreviations, and definitions used in this disclosure are defined at the end of this specification.

[0040] Supports Ethernet data transmission via EPS and 5GS

[0041] Both EPS and 5GS support Ethernet data transmission as part of control plane cellular Internet of Things (CIoT) optimization.

[0042] In EPS, when a UE requests to establish a Packet Data Network (PDN) connection, the UE may indicate the type of data to be transferred over the requested PDN connection by specifying a value for the PDN Type field in the PDN Connection Request message (see [1]). The PDN Type value may indicate "Ethernet" (among other values), thereby indicating that the PDN connection is requested to transfer Ethernet data (see section 9.9.4.10 of [1]).

[0043] Similarly, when a UE requests establishment of a PDU Session in 5GS, the UE may indicate the type of data to be transmitted on the requested session by indicating the value of the PDU Session Type field in the PDU Session Establishment Request message (see [1]). Similarly, "Ethernet" is one of the (multiple) values ​​that can be set for the PDU Session Type field (see section 9.11.4.11 of [2]).

[0044] When the UE transitions from S1 mode to N1 mode, the PDN connection established in S1 mode (ie, in EPS) can be converted to 5GS (ie, N1 mode). Similarly, the PDU session established in N1 mode can be converted to S1 mode.

[0045] For example, when a session is transitioned from N1 mode to S1 mode, the UE must set certain parameters according to some rules defined in [2] (e.g., the PDU session type will become the PDN connection type of the transitioned session, etc.). Below is an excerpt from [2] showing how the corresponding parameters for the transitioned PDN connection from N1 mode to S1 mode are set to the corresponding parameters for the PDU session that will be transitioned from N1 mode to S1 mode. Section 6.1.4.1 contains a complete description of such processing when interworking with EPS.

[0046] The UE creates a corresponding default EPS bearer context and optionally creates (multiple) dedicated EPS bearer contexts using the parameters from each PDU session supporting interworking with EPS as follows:

[0047] a) The PDU Session Type of the PDU Session will be mapped to the PDN Type of the default EPS bearer context as follows:

[0048] 1) If the PDU Session Type is "Unstructured", the PDN Type will be set to "Non-IP";

[0049] 2) If the PDU session type is "IPv4", the PDN type will be set to "IPv4";

[0050] 3) If the PDU session type is "IPv6", the PDN type will be set to "IPv6";

[0051] 4) If the PDU session type is "IPv4v6", the PDN type will be set to "IPv4v6";

[0052] 5) if the PDU Session Type is "Ethernet" and the UE, the network or both do not support Ethernet PDN type in S1 mode, then set the PDN type to "Non-IP"; and

[0053] 6) If the PDU Session Type is "Ethernet" and the UE and the network support Ethernet PDN type in S1 mode, the PDN type will be set to "Ethernet";

[0054] b) The PDU address of the PDU session will be mapped to the PDN address of the default EPS bearer context as follows:

[0055] 1) if the PDU Session Type is "IPv4", "IPv6" or "IPv4v6", the PDN Address of the Default EPS Bearer Context is set to the PDU Address of the PDU Session; and

[0056] 2) If the PDU Session Type is "Ethernet" or "Unstructured", the PDN Address of the Default EPS Bearer Context is set to zero;

[0057] c) The Data Network Name (DNN) of the PDU session will be mapped to the Access Point Name (APN) of the default EPS bearer context;

[0058] d) the access point aggregate maximum bit rate (APN-AMBR) and the extended APN-AMBR received in the parameters of the default EPS bearer context of the mapped EPS bearer context shall be mapped to the APN-AMBR and the extended APN-AMBR of the default EPS bearer context;

[0059] e) for each PDU Session in the PDU SESSION ACTIVE, PDU SESSION MODIFICATION PENDING or PDU SESSION INACTIVE PENDING state, the UE sets the state of the mapped EPS bearer context(s) to BEARER CONTEXTACTIVE; and

[0060] f) For any other PDU Sessions, the UE sets the state of the mapped EPS bearer context(s) to BEARER CONTEXT INACTIVE.

[0061] As mentioned above, when a session is converted from N1 mode to S1 mode, the value of the PDN type is set to the value of the PDU session type. In addition, if the PDU session type is "Ethernet" and the UE and the network support the Ethernet PDN type in S1 mode, the PDN type can be set to "Ethernet".

[0062] IP header compression for control plane CIoT optimization.

[0063] As part of CIoT optimization in EPS and 5GS, IP header compression is defined to be able to compress IP data sent over the control plane. The support of IP header compression and the actual configuration for IP header compression are negotiated between the UE and the network so that the support and actual configuration for IP header compression can be applied to both ends accordingly.

[0064] For example, in 5GS, support for IP header compression for control plane CIoT 5GS optimization is indicated by the UE in the 5G Mobility Management (5GMM) Capability IE (see [2]). The network indicates support (and network acceptance of the use of IP header compression for the UE) in the 5GS Network Feature Support IE (see [2]). If the network allows, the UE negotiates header compression configuration parameters as part of the PDU Session Establishment procedure, or the UE may renegotiate these parameters as part of the PDU Session Modification procedure.

[0065] Note that similar functionality is defined in EPS, namely, UE indication of support for control plane CIoT EPS optimized IP header compression, network indication of support for control plane CIoT EPS optimized IP header compression (and permission to use header compression), and negotiation of configuration parameters between the UE and the network, see [1]. Similarly, in EPS, the negotiation of parameters occurs during establishment of a PDN connection or during modification of a PDN connection (see [1]).

[0066] Ethernet header compression for control plane CIoT optimization.

[0067] Ethernet header compression is not specified in either [1] or [2]. Recently, it was proposed in [2] to apply header compression to Ethernet data via the control plane. The 3GPP standard specifications (see [1] and [2]) introduce capability indication and negotiation between the UE and the network to use this feature, as well as the exchange of compression parameters at the 5G Session Management (5GSM) layer.

[0068] It is an object of certain examples of the present disclosure to at least partially address, solve and / or mitigate at least one of the problems and / or disadvantages associated with the related art, such as at least one of the problems and / or disadvantages described herein. It is an object of certain examples of the present disclosure to provide at least one advantage over the related art, such as at least one of the advantages described herein.

[0069] Other aspects, advantages, and salient features will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses examples of the present disclosure.

[0070] The following description of examples of the present disclosure is provided with reference to the accompanying drawings to assist in a comprehensive understanding of the present disclosure as defined by the claims. The description includes various specific details to assist in understanding, but these are considered to be merely exemplary. Therefore, those of ordinary skill in the art will recognize that various changes and modifications may be made to the examples described herein without departing from the scope of the present disclosure.

[0071] The same or similar components may be denoted by the same or similar reference numerals even though they may be shown in different drawings.

[0072] For the sake of clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure, detailed descriptions of techniques, structures, configurations, functions, or processes known in the art may be omitted.

[0073] The terms and words used herein are not limited to the bibliographic or standard meanings, but, are merely used to enable a clear and consistent understanding of the present disclosure.

[0074] Herein, the words “include,” “comprising,” and “containing,” and variations of these words, such as “including” and “comprising,” mean “including but not limited to,” and are not intended to (and do not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties, and / or combinations thereof.

[0075] Herein, singular forms such as "a," "an," and "the" include plural referents unless the context requires otherwise. For example, reference to "an object" includes reference to one or more of such objects.

[0076] Herein, language of the general form "X for Y" (where Y is an action, procedure, operation, function, activity or step and X is a device for performing the action, procedure, operation, function, activity or step) includes a device X that is specifically adapted, configured or arranged to perform Y, but is not necessarily limited to performing Y.

[0077] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or combinations thereof described or disclosed in conjunction with a particular aspect, embodiment, example, or claim of the present disclosure are to be understood to be applicable to any other aspect, embodiment, example, or claim described herein unless incompatible therewith.

[0078] Specific examples of the present disclosure provide methods, apparatus, and systems for multi-mode interworking of data sessions in a network. The following examples apply to 3GPP 5G and use terms related thereto. For example, specific examples of the present disclosure provide methods, apparatus, and systems for interworking between 5GS and EPS for PDU sessions using header compression in 3GPP 5G. However, those skilled in the art will appreciate that the techniques disclosed herein are not limited to these examples or 3GPP 5G, and may be applied to any suitable system or standard, such as one or more existing and / or future generations of wireless communication systems or standards.

[0079] For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be viewed as entities or features that perform the same or similar roles, functions, operations, or purposes in a network. For example, the functionality of the mobility management entity / session management function (MME / SMF) in the following examples may be applied to any other suitable type of entity that performs mobility / session management functions.

[0080] Those skilled in the art will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:

[0081] -The technology disclosed here is not limited to 3GPP 5G.

[0082] -One or more entities in the examples disclosed herein may be replaced with one or more alternative entities that perform equivalent or corresponding functions, procedures or operations.

[0083] - One or more of the messages in the examples disclosed herein may be replaced by one or more alternative messages, signals, or other types of information carriers conveying equivalent or corresponding information.

[0084] -One or more additional elements, entities and / or messages may be added to the examples disclosed herein.

[0085] - In certain examples, one or more non-essential elements, entities and / or messages may be omitted.

[0086] -The functionality, process or operation of a particular entity in one example may be divided between two or more separate entities in another example.

[0087] -The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example.

[0088] - Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example.

[0089] - Information carried by two or more separate messages in one example may be carried by a single message in an alternative example.

[0090] - In alternative examples, the order in which the operations are performed may be modified if possible.

[0091] - The transmission of information between network entities is not limited to the specific form, type and / or order of messages described in conjunction with the examples disclosed herein.

[0092] Specific examples of the present disclosure may be provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or methods thereof. Specific examples of the present disclosure may be provided in the form of a system (e.g., a network) and / or methods thereof including one or more such apparatus / devices / network entities. For example, in the following examples, a network may include a UE, an access and mobility management function (AMF), an SMF, and / or an MME.

[0093] In view of the relevant technology, there are at least the following problems:

[0094] There is a lack of any specification regarding the application of header compression for sessions transitioning between EPS and 5GS.

[0095] There is currently no specification of what the UE or network can do or assume regarding header compression for sessions transitioning between EPS and 5GS. Although it is expected that header compression may continue to apply to these systems, the local policies in each system may be different. This issue may be more pronounced for Ethernet header compression, which was not introduced in EPS. This raises the question: if header compression is applied in 5GS, how can the UE apply header compression in EPS when EPS has no mechanism (i.e. signaling) to negotiate its use, and what are the actual parameters for Ethernet header compression, if it is allowed?

[0096] Certain examples of the present disclosure address this problem, for which there is no clear description of the UE or the network, resulting in unpredictable behavior.

[0097] In view of the above problems, certain examples of the present disclosure provide one or more of the following solutions.

[0098] Header compression for Ethernet data is only available for 5GS. Therefore, when the session is switched to EPS, the UE stops using header compression. The UE can renegotiate the header compression parameters after switching back to 5GS again.

[0099] New parameters may be introduced to negotiate the support and use of Ethernet header compression in EPS. Therefore, when a session is transitioned from 5GS to EPS, the UE may continue to use the header compression parameters.

[0100] The UE may always renegotiate header compression parameters (e.g., for IP or Ethernet data) at every inter-system change across systems, or after the first inter-system change from EPS to 5GS and for sessions first established in EPS.

[0101] When the UE is in the source system (e.g., EPS), the Ethernet header compression parameters of the target system (e.g., 5GS) can be provided to the UE using the (extended) protocol configuration option IE so that the UE can use these parameters after the inter-system change from the source system (e.g., EPS) to the target system (e.g., 5GS).

[0102] A new IE may be introduced in non-access stratum (NAS) messages in EPS (e.g., for EPS Mobility Management (EMM) NAS messages and EPS Session Management (ESM) NAS messages) so that the UE and the network can indicate their support for Ethernet header compression and, if supported, the UE and the network can negotiate the parameters to be used.

[0103] Specific examples of the present disclosure will now be described in further detail.

[0104] 1. By default, Ethernet header compression is only available on 5GS.

[0105] Specific examples of the present disclosure may apply default behavior. For example, when a PDU session is established in 5GS and Ethernet header compression is supported and allowed for the UE, the UE may assume that Ethernet header compression applies only to the PDU session in 5GS (i.e., N1 mode). Therefore, when the UE transitions to EPS (i.e., S1 mode) and converts the session, the UE cannot assume that Ethernet header compression applies to EPS. Therefore, if the session is successfully converted from N1 mode to S1 mode, the UE may use the session for Ethernet data transmission, but header compression is not applied.

[0106] Alternatively, after accessing S1 mode, the UE may negotiate the use of Ethernet header compression in EPS when sending a Tracking Area Update (TAU) Request message and indicate whether Ethernet header compression for control plane CIoT EPS optimization is supported. When the UE sends an Attach Request message in S1 mode, the UE may also send this IE and set the provided new bit accordingly.

[0107] To this end, a new bit may be provided in the UE Network Capability IE. For example, the bit may be called Ethernet Header Compression for Control Plane CIoT EPS Optimization (EHC-CP CIoT), where, for example, a value of "1" indicates "Ethernet Header Compression for Control Plane CIoT EPS Optimization is supported", and "0" indicates "Ethernet Header Compression for Control Plane CIoT EPS Optimization is not supported".

[0108] Similarly, the network (MME) can indicate whether the UE is supported and allowed to use Ethernet header compression. To this end, a new bit can be provided in the EPS Network Feature Support IE. For example, the bit can be called Ethernet Header Compression for Control Plane CIoT EPS Optimization (EHC-CP CIoT), where, for example, the value "1" indicates "Ethernet Header Compression for Control Plane CIoT EPS Optimization is supported", and "0" indicates "Ethernet Header Compression for Control Plane CIoT EPS Optimization is not supported". When the network indicates support for this feature, the network can also implicitly indicate that the UE is allowed to use this feature.

[0109] The IE with the new bits as described above may be sent by the MME in the TAU Accept message or the Attach Accept message.

[0110] After an inter-system change from N1 mode to S1 mode, for example as described above, the UE may negotiate the use of Ethernet header compression. If the network indicates that Ethernet header compression is not supported (e.g., as described above), the UE may automatically stop using Ethernet header compression (and therefore transmit Ethernet data without header compression) for each of the PDU sessions that have been converted from N1 mode to S1 mode and to which Ethernet header compression was applied in N1 mode. The UE may store the Ethernet header compression parameters negotiated with each SMF while in N1 mode for potential reuse of these parameters when the UE returns from S1 mode to N1 mode and converts a PDN connection (or PDU session) to N1 mode. Alternatively, the UE may discard these parameters. Upon an inter-system change (back) to N1 mode, the UE may renegotiate the use of Ethernet header compression with the network at both the 5GMM layer and the 5GSM layer, as further described below. In one embodiment, if the UE has stored the parameters and the UE returns to 5GS and converts the PDU session, the UE may continue to use the header compression parameters without having to perform a PDU session modification procedure to (renegotiate) these parameters. In one embodiment, the UE may do so if the UE and AMF successfully negotiate the use of header compression as part of the registration process.

[0111] In S1 mode, if the network indicates support for Ethernet header compression, the UE can continue to use the header compression parameters (negotiated in 5GS) for the converted PDN connection (e.g., for Ethernet data or IP data) without renegotiating the parameters with the core network.

[0112] In general, for any session that is considered transferable from one system to another, the UE may set the parameters for IP header compression in the target system to those of the source system. This may be done, for example, as described further below.

[0113] Alternatively, even if the MME indicates support for Ethernet header compression in the EPS Network Feature Support IE, the UE may renegotiate compression parameters for each PDN connection transitioned to S1 mode.

[0114] Those skilled in the art will appreciate that the techniques described herein may be applied bidirectionally, ie, for a PDU session (or PDN connection) transitioning from N1 mode to S1 mode, or from S1 mode to N1 mode.

[0115] Furthermore, those skilled in the art will appreciate that the techniques described herein may be applied to IP header compression for control plane CIoT optimization.

[0116] Currently, EPS does support signaling for IP header compression as described above. Similarly, 5GS supports signaling for IP header compression as described above. However, even for IP header compression, there is no specification of what the UE's behavior may be when the UE transitions across S1 mode and N1 mode and converts a PDN connection (or PDU session) across EPS and 5GS systems. Those skilled in the art will appreciate that the techniques described herein may also be applied to IP header compression.

[0117] For example, since signaling and support for IP header compression is already supported in both systems, the UE can automatically keep using the same IP header compression parameters when the UE transitions between 5GS and EPS and converts sessions between N1 mode and S1 mode (or vice versa). Alternatively, as described above, when the network indicates support (and implicitly indicates permission) for the feature, the UE can still negotiate the header compression parameters when transitioning to the target system.

[0118] Alternatively, for a PDU session whose PDU type is Ethernet and use of Ethernet header compression is allowed, the UE may consider such a PDU session not convertible to EPS even if all other criteria for such determination are met. In one embodiment, if other criteria for convertibility to a target system (e.g., S1 mode) are met, the UE may convert the session, but may not use Ethernet header compression in the target system.

[0119] To apply the parameters received in the source system to the target system, the following steps can be performed.

[0120] In the following examples, it is first assumed that the UE is in 5GS and has a PDU session using header compression.

[0121] Both the UE and the AMF may consider the header compression parameters not to be per PDU session, but per a specific QoS flow identified by a Quality of Service (QoS) Flow Identifier (QFI) (within a PDU session). In one embodiment, by default, the header compression parameters that may be associated with a QoS flow may be the QFI of the default QoS flow, i.e., the default QoS rule.

[0122] The UE may consider the received header compression parameters to be associated with the QFI of the PDU session (and optionally, the QFI of the default QoS rule). For S1 mode (optionally, when the UE transitions from N1 mode to S1 mode and converts the PDU session), the UE may also consider the header compression parameters to be associated with the EPS bearer identifier, which is associated with the QFI, and the header compression parameters for the QFI are received in N1 mode. In one embodiment, by default, the UE may consider the header compression parameters to be associated with the EPS bearer identifier of the default EPS bearer. In this way, for a PDU session in 5GS, the header compression parameters of the PDU session (or the header compression parameters of the QoS flow identified by the QFI (optionally, the QFI of the default QoS rule)) can be mapped to the header compression parameters of the EPS bearer identifier associated with the QFI (optionally, the QFI of the default QoS rule) (so optionally, the EPS bearer identifier is the EPS bearer identifier of the default EPS bearer).

[0123] In the following, it is now assumed that the UE is in EPS and a PDN connection using header compression is established. Similarly, for a UE in EPS, the header compression parameters can be considered to be associated with the EPS bearer identifier. Therefore, the UE (for example, when changing between systems from S1 mode to N1 mode) can consider that the received header compression parameters are also associated with the QoS flow identified by the QFI, which is associated with the EPS bearer identifier for which its header compression parameters are received. In one embodiment, the association between the EPS bearer identifier and the QoS rules can be via the QFI, which can be sent in a QoS flow description containing the EPS bearer identifier and the QFI. Therefore, the QoS rules associated with the EPS bearer identifier can be determined by the QFI in the QoS flow description containing the EPS bearer identifier.

[0124] In one embodiment, upon inter-system change from S1 mode to N1 mode, the UE may associate header compression parameters with a PDU session identified by a PDU session identifier (ID) parameter in the (E)PCO IE received in EPS (ie, S1 mode).

[0125] Those skilled in the art will appreciate that the above techniques may also be applied to IP header compression and / or Ethernet header compression.

[0126] In this way, when the UE transitions from S1 mode to N1 mode and converts the PDU session, the UE can associate the header compression parameters to the QoS flow (or QoS rule) identified by the QFI associated with the EPS bearer identifier whose header compression parameters were received in the EPS.

[0127] Those skilled in the art will appreciate that the above techniques may be applied to IP header compression parameters and / or Ethernet header compression parameters, or any other header compression parameters that have been defined or may be defined in the future.

[0128] In a specific example of the present disclosure, whenever the network sends a header compression parameter to the UE in any 5GSM message, the network may indicate the QFI associated with the header compression parameter. This may be done in any suitable manner, for example, an IE carrying the header compression parameter (e.g., a Header Compression Configuration IE, or any other suitable name that may be given to such an IE) may include a field indicating the QFI associated with the parameter. Alternatively, the QoS Flow Description IE may include a field containing an indication that the QFI of the QoS Flow Description is associated with the Header Compression Parameter. Alternatively, the QoS Flow Description may include a new parameter that is the Header Compression Parameter associated with the QFI.

[0129] 2. Renegotiate the header compression parameters in the target system.

[0130] In a specific example of the present disclosure, the following UE behavior may be applied when the UE behavior transitions to a target system, where the target system may be S1 mode (e.g., after an inter-system change from N1 mode), or the target system may be N1 mode (e.g., after an inter-system change from S1 mode).

[0131] The following description relates to IP header compression. However, those skilled in the art will appreciate that these techniques can be applied to Ethernet header compression.

[0132] Assume that a PDN connection is first established in S1 mode (i.e., the connection is not the result of a PDU session transition from N1 mode to S1 mode), and for that connection the UE and the network may have negotiated the use of IP header compression. Upon an inter-system change to a target system, i.e., for N1 mode in this example (the techniques described herein may also be applied in the reverse case), the UE may renegotiate IP header compression parameters with each SMF for which the corresponding PDU session was transitioned. This may be done in addition to the negotiation at the 5GMM layer as described above, in accordance with the current behavior in [2]. Thus, in order to negotiate the parameters with the SMFs, the UE may perform a PDU session modification procedure after the first inter-system change to the target system (i.e., in this example, after the first inter-system change from S1 mode to N1 mode) to renegotiate the header compression parameters. In one embodiment, the UE may always renegotiate these parameters after each inter-system change. Therefore, support for header compression and the presence of a PDU Session for which header compression was applied in the source system (or for which header compression was not applied in the source system) may be a trigger for performing a PDU Session Modification procedure (i.e. the UE may send a PDU Session Modification Request message) to (re)negotiate header compression parameters in the target system (e.g. in N1 mode). Alternatively, if header compression was used in the source system and was modified at least once in the source system, this may be a trigger for the UE to renegotiate these parameters by initiating a PDU Session Modification procedure in N1 mode.

[0133] Those skilled in the art will understand that the technology of the UE performing the PDU session modification process after the inter-system change from S1 mode to N1 mode can also be applied to the above-mentioned technology titled "Ethernet header compression only applies to 5GS by default", that is, if a session is first established in N1 mode and the UE converts the session to S1 mode, then when the UE returns to N1 mode, the UE can perform the PDU session modification process to negotiate header compression parameters with the network.

[0134] Similarly, when the UE performs an inter-system change from N1 mode to S1 mode, the UE may perform a bearer resource modification procedure (e.g., sending a BEARER RESOURCE MODIFICATION REQUEST message) to negotiate compression parameters for the PDN connection or each EPS bearer. The same trigger described here for performing a PDU session modification (after an inter-system change to N1 mode) may also be applied in EPS (i.e., after an inter-system change to S1 mode) so that the UE may perform a bearer resource modification procedure to negotiate compression parameters.

[0135] In a specific example of the present disclosure, when the UE is in 5GS, as part of the PDU session establishment process, or as part of the PDU session modification process, the network (SMF in this case) may provide header compression parameters (e.g., for IP header compression or Ethernet header compression) for the target system in a Protocol Configuration Option (PCO) IE or an Extended PCO IE (EPCO IE). For example, when the UE is in N1 mode, if the PDU session is to be converted to EPS, the SMF may send the configuration parameters of the target system. This enables the UE to know these parameters in advance. Therefore, when in the target system (S1 mode in this case) and the network notifies the UE that header compression is allowed (on the EMM layer), the UE may use the received parameters to perform header compression.

[0136] Here, the term "header compression" may refer to, for example, header compression parameters for IP (ie, IP header compression parameters) or header compression parameters for Ethernet (ie, Ethernet header compression parameters).

[0137] Similarly, in EPS, the PDN Gateway Control Plane + Session Management Function (PGW-C + SMF) node can provide the UE with header compression parameters that can be used for the target system (in this example, the target system is N1 mode). Similarly, when the UE enters N1 mode and converts the PDU session to N1 mode, it can use the previously received parameters for the converted PDU session.

[0138] The parameters provided by the source system (e.g., by the core network of EPS) in the PCO IE or EPCO IE may include Ethernet header compression parameters or IP header compression parameters. Once received, the UE may treat the received parameters as parameters to be used when the UE enters the target system (e.g., 5GS) for the converted PDU session.

[0139] Therefore, a new parameter may be defined for the (E)PCO IE, where the new parameter identifies the header compression parameters for Ethernet. The parameter identifier may indicate, for example, Ethernet header compression for the target system, or Ethernet header compression parameters for N1 mode (provided to the UE in S1 mode), or Ethernet header compression parameters for S1 mode (provided to the UE in N1 mode). In addition to the parameter identifier, the (E)PCO IE may also contain the actual header compression parameters, which will be the value part of the Ethernet Header Compression IE (if this IE is defined in [1] or [2]).

[0140] Those skilled in the art will appreciate that this technique may be applied to IP header compression parameters.

[0141] In summary, in a specific example of the present disclosure, when the UE is in, for example, S1 mode, the network (e.g., PGW-C+SMF entity) can use new parameters (e.g., parameter identifier and content) in the (E)PCO sent to the UE in ESM signaling to provide the UE with Ethernet header compression parameters to be used in N1 mode, for example, as part of an activate default EPS bearer request message or any other ESM message. When these parameters are received in the UE, assuming that the PDU session is successfully converted to the target system, the UE can store these parameters and use them after the inter-system change to the target system (e.g., N1 mode in this example).

[0142] In the specific example of the present disclosure, the source system is in S1 mode, and the target system is in N1 mode. However, those skilled in the art will appreciate that the techniques described herein may be applied if the source system is any other system, such as N1 mode, and the target system is any other system, such as S1 mode. Furthermore, those skilled in the art will appreciate that the techniques described herein may be applied to other types of data, not just Ethernet data.

[0143] In a specific example, the techniques described herein for a UE and / or a network may be conditional on the presence of an N26 interface in the network and / or the operation of the UE in a single registration mode. However, those skilled in the art will appreciate that the techniques described herein may still be applied even if N26 is not supported in the network or even if the UE operates in a dual registration mode.

[0144] 3. Definition and use of Ethernet header compression in EPS.

[0145] In a specific example of the present disclosure, to ensure that Ethernet header compression can be used across EPS and 5GS for sessions that are transitioned between these systems, or to determine that a session can be transitioned between EPS and 5GS, EPS can implement a mechanism to indicate whether Ethernet header compression is supported at the EMM layer and the ESM layer.

[0146] For example, for the EMM layer, the techniques described in the previous sections may apply the definition and use of new bits, for example, sent by the UE in the UE Network Capabilities IE and by the network in the EPS Network Feature Support IE.

[0147] For UEs supporting Ethernet header compression, and optionally, when the network has indicated that the network supports (and implicitly indicates that the network allows use of) Ethernet header compression for the UE, the UE may include a new IE, such as Header Compression Parameters of the Ethernet IE, in the PDN Connection Request message.

[0148] The UE may also perform a bearer resource modification procedure (ie, send a BEARER RESOURCE MODIFICATION REQUEST message) to negotiate compression parameters for the PDN connection or each EPS bearer, and include the new IE in the ESM message.

[0149] Similarly, in a specific example, optionally when the PDN Connection Request message includes a Header Compression Parameters IE, such as Header Compression Parameters of Ethernet IE, the MME may include a new similar IE (indicating the negotiated Header Compression Parameters) in the Activate Default EPS Bearer Context Request message.

[0150] Similarly, in a specific example, optionally in response to receiving a BEARER RESOURCEMODIFICATION REQUEST message with a new IE to (re)negotiate header compression parameters, the MME may include a new similar IE (indicating the negotiated header compression parameters) in the MODIFY EPS BEARER CONTEXT REQUEST message.

[0151] Those skilled in the art will appreciate that the names of the IEs described herein are provided only as examples and that any other suitable names may be used.

[0152] Those skilled in the art will appreciate that the techniques described herein may be applied in any suitable combination and may be applied to the interworking of IP header compression and PDU sessions (or PDN connections) for transporting IP data. Those skilled in the art will also appreciate that the techniques described herein may be applied to UEs using control plane CIoT EPS optimization and / or control plane CIoT5GS optimization, but are not limited to these examples. Those skilled in the art will appreciate that the techniques described herein may be applied to 5GS (N1 mode) and EPS (S1 mode) accordingly. Those skilled in the art will appreciate that the techniques described herein may be used in any combination and / or order.

[0153] There is currently no description or assumption about the applicability of IP header compression (supported in both EPS and 5GS) when a session transitions between S1 mode or N1 mode. Specific examples of this disclosure specify UE and network behavior in this case. For example, in a specific example, when a session successfully transitions across systems, the UE may continue to use IP header compression for the session.

[0154] In a specific example of the present disclosure, Ethernet header compression is applied only to 5GS by default. Therefore, when the UE transitions to EPS, optionally after negotiation with the network, the UE can convert the session but not apply compression.

[0155] In a specific example of the present disclosure, the UE may always renegotiate the compression parameters to be used (eg, for IP or Ethernet data types) after each inter-system change. The UE may use appropriate NAS signaling of the target system to renegotiate the parameters to be used.

[0156] In order to efficiently and uninterruptedly apply header compression to Ethernet data, in a specific example of the present disclosure, NAS signaling in EPS can be updated so that the UE and the network can indicate their support for Ethernet header compression and also negotiate related parameters. In this way, when the session is converted between EPS and 5GS, the UE can continue to use the same Ethernet header compression parameters.

[0157] It will be appreciated by those skilled in the art that the present disclosure is not limited to the examples outlined above.

[0158] For example, a specific example of the present disclosure provides a method for a UE, wherein the UE operates in a first mode (e.g., 5GS or EPS) and wherein a data session (e.g., a PDU session or a PDN connection) is established for the UE, the method comprising: switching from the first mode to a second mode (e.g., EPS or 5GS), including converting the data session from the first mode to the second mode; and applying a policy to determine whether to apply header compression to the data session in the second mode.

[0159] In a specific example, applying the policy may include, if header compression is applied to the data session in the first mode, ceasing to apply header compression to the data session in the second mode.

[0160] In a specific example, applying the policy may include, if header compression is applied to the data session in the first mode and header compression is not supported in the second mode, ceasing to apply header compression to the data session in the second mode.

[0161] In a specific example, applying the policy may include, if header compression was applied to the data session in the first mode, continuing to apply header compression to the data session in the second mode.

[0162] In certain examples, the method may also include negotiating one or more parameters for header compression in the second mode.

[0163] In a specific example, a data session may first be established in a first mode (and optionally, one or more parameters for header compression in the first mode have been negotiated, and optionally, the switch is the first switch between modes for the data session), and the method may further include, if header compression is supported in the second mode (and optionally, if the data session uses header compression in the first mode), performing a data session modification procedure (e.g., a PDU session modification procedure or a bearer resource modification procedure) to negotiate parameters for header compression in the second mode.

[0164] In a particular example, the negotiation can include sending (e.g., in a TAU request message or an attach request message) an indicator (e.g., a bit provided in a UE network capabilities IE) indicating support for header compression in a second mode (e.g., Ethernet header compression for CP CIoT EPS optimization).

[0165] In a specific example, the method may also include using, for header compression in the second mode, one or more parameters corresponding to one or more parameters previously used for header compression in the first mode.

[0166] In a particular example, parameters for header compression in a first mode are associated with a QFI of a data session, wherein parameters for header compression in a second mode are associated with an EPS bearer identifier associated with the QFI, and wherein parameters associated with the QFI are mapped to parameters associated with the EPS bearer identifier associated with the QFI.

[0167] In a specific example, the method may further include: switching from the second mode to the first mode, including converting the data session from the second mode to the first mode; and if header compression is applied to the data session in the second mode, continuing to apply header compression to the data session in the first mode.

[0168] In a particular example, the method may also include negotiating one or more parameters of header compression in the first mode.

[0169] In a specific example, the method may also include: storing one or more parameters for header compression in the first mode when switching from the first mode to the second mode; and retrieving the stored parameters and using the retrieved parameters for header compression in the first mode when switching from the second mode to the first mode.

[0170] In a specific example, the method may further include: receiving one or more parameters for header compression in the first mode or the second mode from a network entity (eg, SMF or PGW-C+SMAF); and storing the received parameters.

[0171] In a particular example, receiving parameters from a network entity may include receiving one or more parameters for header compression in a second mode in a first mode (e.g., as part of a data session establishment procedure or a data session modification procedure), and the method may also include applying the received parameters in the second mode.

[0172] In a particular example, receiving parameters from a network entity may include receiving one or more parameters for header compression in a first mode in a second mode (e.g., as part of a data session establishment procedure or a data session modification procedure), and the method may also include applying the received parameters in the first mode.

[0173] In a specific example, the header compression parameters may be identified in the parameters of the (E)PCO IE and / or the header compression parameters may be included in the (E)PCO.

[0174] In a specific example, header compression may include at least one of IP header compression and Ethernet header compression.

[0175] Certain examples of the present disclosure provide a UE or network entity configured to operate according to the method of any of the preceding examples.

[0176] Certain examples of the present disclosure may provide a network including a network entity and / or a UE according to the aforementioned examples.

[0177] Certain examples of the present disclosure provide a computer program comprising instructions which, when executed by a computer or a processor, cause the computer or the processor to perform a method according to any of the foregoing examples.

[0178] Certain examples of the present disclosure provide a computer or processor readable data carrier having stored thereon a computer program according to the foregoing examples.

[0179] Figure 1 A block diagram of an exemplary network entity according to an embodiment of the present disclosure is shown. Figure 1 In the embodiment, the transmitter 103 and the receiver 105 may be implemented in a transceiver. For example, the transceiver may send a signal via the transmitter 103 and receive a signal via the receiver 105. For example, the UE, AMF, SMF, MME and / or any other suitable network entity may be implemented in a manner as follows: Figure 1 It is provided in the form of the network entity shown. Those skilled in the art will understand that Figure 1 The network entities shown in may be implemented, for example, as network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on an appropriate platform (eg, on a cloud infrastructure).

[0180] The entity 100 includes a processor (or controller) 101, a transmitter 103, and a receiver 105. The receiver 105 is configured to receive one or more messages or signals from one or more other network entities. The transmitter 103 is configured to send one or more messages or signals to one or more other network entities. The processor 101 is configured to perform one or more operations and / or functions as described above. For example, the processor 101 may be configured to perform the operations of the UE, AMF, SMF, and / or MME.

[0181] Figure 2 A block diagram of a UE 200 according to an embodiment of the present disclosure is shown.

[0182] refer to Figure 2 , the UE may include a transceiver 220, a memory 230, and a processor 210. The transceiver 220, the memory 230, and the processor 210 of the UE may operate according to the communication method of the UE described above. However, the components of the UE are not limited thereto. For example, the UE may include Figure 2 More or fewer components are shown. In addition, the transceiver 220, the memory 230 and the processor 210 may be implemented in the form of a single chip.

[0183] The transceiver 220 may transmit and receive signals to and from a base station. Here, the signal may include control information and data. In this regard, the transceiver 220 may include a radio frequency (RF) transmitter that up-converts and amplifies the frequency of a transmitted signal and an RF receiver that performs low noise amplification on a received signal and down-converts the frequency. However, these components of the transceiver 220 are merely examples and are not limited to the RF transmitter and the RF receiver.

[0184] In addition, the transceiver 220 may receive a signal via a wireless channel and output the signal to the processor 210 , and transmit a signal output from the processor 210 via a wireless channel.

[0185] The memory 230 may store programs and data required for UE operation. In addition, the memory 230 may store control information or data included in a signal obtained by the UE. The memory 230 may include a storage medium such as a read-only memory (ROM), a random access memory (RAM), a hard disk, a CD-ROM, or a DVD, or a combination thereof. In addition, the memory 230 may include a plurality of memories. According to an embodiment of the present disclosure, the memory 230 may store a program for performing header compression according to an embodiment of the present disclosure.

[0186] The processor 210 may control a series of processes so that the UE operates according to the embodiments of the present disclosure. For example, according to the embodiments of the present disclosure, the processor 210 may control the transceiver 220 and the memory 230 to perform random access. Here, with respect to the operation of the processor 210, only some operations of the embodiments of the present disclosure are described, but the processor 210 may control all processes so that the UE may operate according to all or some of the embodiments of the present disclosure.

[0187] Figure 3 A block diagram of a core network entity 300 according to an embodiment of the present disclosure is shown.

[0188] refer to Figure 3 , the core network entity may include a transceiver 320, a memory 330, and a processor 310. The transceiver 320, the memory 330, and the processor 310 of the core network entity may operate according to the communication method of the core network entity described above. However, the components of the core network entity are not limited thereto. For example, the core network entity may include Figure 3 More or less components are shown. In addition, the transceiver 320, the memory 330 and the processor 310 can be implemented in the form of a single chip. According to an embodiment, the core network entity may include a base station and an entity included in the core network. The core network entity may include the above-mentioned NF, and may include, for example, AMF, SMF, etc. In various embodiments, the core network entity may refer to a network entity.

[0189] The transceiver 320 can send and receive signals to and from a UE, a core network entity, or a base station. Here, the signal may include control information and data. In this regard, the transceiver 320 may include an RF transmitter that up-converts and amplifies the frequency of the transmitted signal and an RF receiver that performs low noise amplification and down-converts the frequency of the received signal. However, these components of the transceiver 320 are only examples and are not limited to the RF transmitter and the RF receiver.

[0190] In addition, the transceiver 320 may receive a signal via a wireless channel and output the signal to the processor 310 , and transmit a signal output from the processor 310 via a wireless channel.

[0191] The memory 330 may store programs and data required for the operation of the core network entity. In addition, the memory 330 may store control information or data included in a signal obtained by the core network entity. The memory 330 may include a storage medium such as a read-only memory (ROM), a random access memory (RAM), a hard disk, a CD-ROM or a DVD or a combination thereof. In addition, the memory 330 may include a plurality of memories. According to an embodiment of the present disclosure, the memory 330 may store a program for supporting beam-based cooperative communication.

[0192] The processor 310 may control a series of processes so that the core network entity operates according to the embodiments of the present disclosure. The processor 310 may only perform some operations of the embodiments of the present disclosure, but alternatively, may control all processes so that the core network entity operates according to all or some of the embodiments of the present disclosure.

[0193] The technology described herein can be implemented using any appropriately configured device and / or system. Such a device and / or system can be configured to perform a method according to any aspect, embodiment, example or claim disclosed herein. Such a device may include one or more elements, such as one or more of a receiver, a transmitter, a transceiver, a processor, a controller, a module, a unit, etc., each of which is configured to perform one or more corresponding processes, operations and / or method steps to implement the technology described herein. For example, the operation / function of X can be performed by a module (or X module) configured to perform X. One or more elements can be implemented in the form of hardware, software, or any combination of hardware and software.

[0194] It should be understood that the examples of the present disclosure may be implemented in the form of hardware, software, or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage (e.g., a storage device such as ROM, whether erasable or rewritable), or in the form of a memory (e.g., RAM, a memory chip, a device, or an integrated circuit), or on an optical or magnetically readable medium (e.g., a CD, DVD, a disk, or a tape, etc.).

[0195] It should be understood that storage devices and storage media are embodiments of machine-readable storage that are suitable for storing one or more programs including instructions that, when executed, implement specific examples of the present disclosure. Therefore, specific examples provide programs including code for implementing methods, devices, or systems according to any example, embodiment, aspect, and / or claim disclosed herein, and / or machine-readable storage storing such programs. In addition, such programs can be transmitted electronically via any medium, such as a communication signal transmitted via a wired or wireless connection.

[0196] While the present disclosure has been shown and described with reference to particular examples, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the present disclosure as defined by the appended claims.

[0197] Although the present disclosure has been described with various embodiments, various changes and modifications may occur to those skilled in the art. The present disclosure is intended to encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1. A method for a user equipment UE in a wireless communication system, the method comprising: identifying an inter-system change from a first mode to a second mode; Sending a request message to a network entity, the request message including first information related to whether the UE supports header compression for control plane CIoT 5GS optimization, wherein the first information is indicated by a value included in a capability information element IE of the request message; receiving an acceptance message from the network entity, the acceptance message including second information related to whether the header compression is supported; and Initiating a modification procedure for negotiating a header compression configuration based on first information indicating that the UE supports header compression, second information indicating that header compression is supported, and that the UE operates in a single registration mode in a network supporting an N26 interface, Wherein, in a case where the first mode is the S1 mode and the second mode is the N1 mode, the request message is a message for requesting registration, and Wherein, the header compression configuration is negotiated based on a modification process.

2. The method according to claim 1, in, In case that the first mode is the N1 mode and the second mode is the S1 mode, the request message is a message for requesting tracking area update.

3. The method according to claim 1, in, When the header compression is supported, the value indicates 1, and when the header compression is not supported, the value indicates 0.

4. The method according to claim 1, in, The accept message includes a network feature support information element IE, and the second information is indicated by a value of the network feature support IE, When the header compression is supported, the value of the network feature support IE indicates 1, and when the header compression is not supported, the value of the network feature support IE indicates 0.

5. The method according to claim 1, wherein: When the first mode is the N1 mode and the second mode is the S1 mode, the header compression is Internet Protocol IP header compression.

6. The method according to claim 1, wherein: When the first mode is the S1 mode and the second mode is the N1 mode, the header compression is one of IP header compression and Ethernet header compression.

7. A method for a network entity in a wireless communication system for inter-system change from a first mode to a second mode, the method comprising: Receiving a request message from a user equipment UE, the request message comprising first information related to whether the UE supports header compression for control plane CIoT 5GS optimization, wherein the first information is indicated by a value included in a capability information element IE of the request message; Sending an acceptance message to the UE, where the acceptance message includes second information related to whether the header compression is supported; Wherein, based on the first information indicating that the UE supports header compression, the second information indicating that the header compression is supported, and the UE operating in a single registration mode in a network supporting the N26 interface, a modification process for negotiating a header compression configuration is initiated, Wherein, in the case where the UE changes from the first mode S1 mode to the second mode N1 mode between systems, the request message is a message for requesting registration, and Wherein, the header compression configuration is negotiated based on a modification process.

8. The method according to claim 7, in, When the header compression is supported, the value indicates 1, and when the header compression is not supported, the value indicates 0.

9. The method according to claim 7, in, The accept message includes a network feature support information element IE, and the second information is indicated by a value of the network feature support IE, When the header compression is supported, the value of the network feature support IE indicates 1, and when the header compression is not supported, the value of the network feature support IE indicates 0.

10. The method according to claim 7, wherein: When the first mode is the N1 mode and the second mode is the S1 mode, the header compression is Internet Protocol IP header compression.

11. The method according to claim 7, wherein: When the first mode is the S1 mode and the second mode is the N1 mode, the header compression is one of IP header compression and Ethernet header compression.

12. A user equipment UE (200) in a wireless communication system, the UE (200) comprising: transceiver (220); and At least one processor (210), operably connected to the transceiver (220), the at least one processor (210) being configured to: Sending a request message to a network entity, the request message including first information related to whether the UE supports header compression for control plane CIoT 5GS optimization, wherein the first information is indicated by a value included in a capability information element IE of the request message; receiving an acceptance message from the network entity, the acceptance message including second information related to whether the header compression is supported; and Initiating a modification procedure for negotiating a header compression configuration based on first information indicating that the UE supports header compression, second information indicating that header compression is supported, and that the UE operates in a single registration mode in a network supporting an N26 interface, Wherein, in a case where the first mode is the S1 mode and the second mode is the N1 mode, the request message is a message for requesting registration, and Wherein, the header compression configuration is negotiated based on a modification process.

13. The UE according to claim 12, in, When the header compression is supported, the value indicates 1, and when the header compression is not supported, the value indicates 0.

14. The UE according to claim 12, in, The accept message includes a network feature support information element IE, and the second information is indicated by a value of the network feature support IE, When the header compression is supported, the value of the network feature support IE indicates 1, and when the header compression is not supported, the value of the network feature support IE indicates 0.

15. The UE according to claim 12, in, When the first mode is the N1 mode and the second mode is the S1 mode, the header compression is Internet Protocol IP header compression, and When the first mode is the S1 mode and the second mode is the N1 mode, the header compression is one of IP header compression and Ethernet header compression.

Images