Method and apparatus for non-access stratum protocol header optimization in mobile communications

Abstract

Techniques related to non-access stratum (NAS) protocol header optimization in mobile communications are described. An apparatus (e.g., a user equipment (UE)) communicates with a network involving support for NAS or access stratum (AS) message overhead reduction signaling functionality. The apparatus communicates with the network for control plane (CP) data transfer with reduced overhead in a NAS protocol header.

Description

[0001] Cross-references

[0002] This disclosure claims priority to Indian patent applications 202421082376, 202421082794 and 202421090005, filed on 28 October 2024, 29 October 2024 and 20 November 2024, respectively, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to mobile communications, and more specifically, to the optimization of non-access stratum (NAS) protocol headers in mobile communications. Background Technology

[0004] In the current third-generation cooperation project (3 rd In wireless communications under the Generation Partnership Project (3GPP) specifications, such as cellular Internet-of-Things (CIoT), Internet-of-Things (IoT), and non-terrestrial network (NTN) devices, the non-access stratum (NAS) protocol overhead currently used for control plane (CP) data transmission is a significant problem. This is because NAS overhead is substantial and typically involves small data loads, easily leading to inefficient CP data transmission, particularly in IoT NTN systems, where it consumes more radio frequency (RF) resources during network transmission, negatively impacting load delivery and latency. At the time of this disclosure, no mechanism has been defined to address this NAS protocol overhead issue, and support for overhead solutions cannot be indicated between user equipment (UE) and the network.

[0005] Therefore, a solution for optimizing the NAS protocol header is needed in mobile communications. Summary of the Invention

[0006] The following abstract is for illustrative purposes only and is not intended to be limiting in any way. That is, the following abstract aims to introduce the concepts, key points, benefits, and advantages of the novel and non-obvious techniques described herein. Some embodiments will be further elaborated in the detailed description below. Therefore, the following abstract is not intended to identify the essential features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter.

[0007] One objective of this disclosure is to propose solutions or strategies for addressing the problems described herein. More specifically, the various solutions proposed in this disclosure are believed to provide solutions related to the optimization of non-access stratum (NAS) protocol headers in mobile communications. It is believed that implementations of one or more of the solutions proposed herein can solve or alleviate the aforementioned problems.

[0008] In one aspect, a method may involve user equipment (UE) communicating with a network, involving support for reduced NAS or access stratum (AS) message overhead for control plane (CP) data transmission. The method may also involve the UE, in response to both the UE and the network indicating support for such reduced overhead for CP data transmission, performing CP data transmission with the network using a new message in the NAS header containing reduced overhead.

[0009] In another aspect, a method may involve a network node communicating with a UE, involving support for reduced NAS or AS message overhead for CP data transmission. The method may also involve the network node, in response to indications from both the UE and the network supporting such reduced overhead for the CP data transmission, performing the CP data transmission with the UE using a new message with reduced overhead in the NAS header.

[0010] In another aspect, an apparatus implementable in a UE may include a transceiver configured for wireless communication and a processor coupled to the transceiver. The processor may communicate with a network via the transceiver, relating to support for reduced NAS or AS message overhead for CP data transmission. The processor may also, in response to both the UE and the network indicating support for such reduced overhead for the CP data transmission, perform the CP data transmission with the network via the transceiver, employing a new message with reduced overhead in the NAS header.

[0011] It is worth noting that although the content described herein may be within the context of certain wireless access technologies, networks, and network topologies, such as 5G New Radio (NR) / Beyond Fifth-Generation (B5G) / 6G mobile communications, the proposed concepts, schemes, and any variations / derivatives thereof can be implemented, used, and implemented by other types of wireless access technologies, networks, and network topologies, such as, but not limited to, 4G / Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, Internet of Things (IoT), Narrow B and Internet of Things (NB-IoT), Industrial Internet of Things (IIoT), Vehicle-to-Everything (V2X), and non-terrestrial network (NTN) communications. Therefore, the scope of this disclosure is not limited to the examples described herein. Attached Figure Description

[0012] The accompanying drawings are included in this disclosure to provide a further understanding of the disclosure and form part of it. The drawings illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. It will be understood that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual dimensions in order to clearly illustrate the concepts of the disclosure.

[0013] Figure 1 This is a schematic diagram of an example network environment in which various solutions and schemes related to this disclosure can be implemented.

[0014] Figure 2 This is a block diagram of an example communication system based on the scheme proposed in this disclosure.

[0015] Figure 3 This is a flowchart of a second example process under the scheme proposed in this disclosure.

[0016] Figure 4 This is a flowchart of a second example process under the scheme proposed in this disclosure. Detailed Implementation

[0017] Detailed embodiments and implementations of the claimed subject matter are disclosed herein. However, it should be understood that the disclosed embodiments and implementations are merely examples of the claimed subject matter, which may be implemented in various forms. This disclosure may take many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided to make the description of this disclosure exhaustive and complete, and to fully communicate the scope of this disclosure to those skilled in the art. In the following description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.

[0018] Overview

[0019] According to the implementation of this disclosure, various techniques, methods, schemes, and / or solutions related to the optimization of non-access stratum (NAS) protocol headers in mobile communications are involved. According to this disclosure, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions are described separately below, two or more solutions can be implemented in some combination.

[0020] Figure 1 An example of a network environment 100 is provided, in which various solutions and schemes related to this disclosure can be implemented. Figures 2-4 Examples of various proposed solutions in network environment 100 according to this disclosure are provided. The following description of the various proposed solutions is in conjunction with… Figures 1-4 It was carried out.

[0021] See Figure 1Network environment 100 involves user equipment (UE) 110 communicating wirelessly with wireless network 120 (e.g., a mobile network comprising non-terrestrial network (NTN) and terrestrial network (TN)) via terrestrial network node 125 (e.g., evolved Node-B (eNB), Next Generation Node-B (gNB), or transmission / reception point (TRP)) and / or non-terrestrial network node 128 (e.g., satellite). For example, terrestrial network node 125 and / or non-terrestrial network node 128 may form an NTN serving cell for communicating wirelessly with UE 110. In some implementations, UE 110 may be an Internet of Things (IoT) device, such as an NB-IoT UE or an enhanced machine-type communication (eMTC) UE (e.g., a bandwidth-reduced low complexity (BL) UE or a coverage enhancement (CE) UE). In such a communication environment, UE 110, network 120, terrestrial network node 125 and non-terrestrial network node 128 may implement various schemes related to NAS protocol header optimization in mobile communication in accordance with this disclosure, as described below.

[0022] It is worth noting that although the various proposed schemes are described individually or separately below, in actual implementation, some or all of the proposed schemes can be used in combination or implemented in other ways. Of course, each proposed scheme can also be used or implemented individually or separately. In addition, as used in this article, "lower layer" can refer to the layer below the radio resource control (RRC) layer in the 5th Generation Mobility Management (5GMM) protocol stack, such as the packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, medium access control (MAC) layer, physical (PHY) layer, etc.

[0023] According to the scheme proposed in this disclosure, in the context of capability negotiation, the UE (e.g., UE 110) and the network (e.g., wireless network 120 via network node 125 and / or non-terrestrial network node 128) may negotiate and / or instruct support for NAS / access stratum (AS) message overhead reduction signaling functions using any of the following mechanisms.

[0024] In the first mechanism, the UE can send new / existing bits in an existing information element (IE) of a given Mobility Management (MM), where the MM is 6th Generation Mobility Management (6GMM), 5GMM, Evolved Packet System (EPS) Mobility Management (EMM), etc., or send them to the network in a new IE in an existing / new message to indicate its support for NAS / AS message overhead reduction signaling function in messages such as registration request, service request, and attach request.

[0025] In the second mechanism, if the network supports NAS / AS message overhead reduction signaling function, the network can indicate to the UE in existing / new bits / new IEs in existing / new messages (e.g., registration acceptance, service acceptance, configuration update command, attach acceptance, etc.).

[0026] In the third mechanism, the UE can be configured to support the NAS / AS message overhead reduction feature, and / or the UE can support the reduced NAS / AS message overhead reduction feature when the UE is configured / instructed to enable the feature through a Management Object (MO) configuration mechanism or through information stored in the Universal Subscriber Identity Module (USIM) associated with the UE. If the feature is enabled through MO configuration or USIM or security packets, the UE can use the NAS / AS message overhead reduction feature. Furthermore, support for the NAS / AS message overhead reduction signaling feature can be passed to the UE through USIM configuration, MO (e.g., NAS MO), or security packets (e.g., Short Message Service (SMS)).

[0027] In the fourth mechanism, the network can indicate to the UE in any AS message the support for NAS / AS message overhead reduction signaling functions (e.g., RRC connection / reconfiguration, existing / new system information block (SIB)).

[0028] According to the scheme proposed in this disclosure, in the context of existing protocol discriminators (PDs), when the UE supports the NAS / AS message overhead reduction function, the UE can use existing protocol discriminators (e.g., service request messages or control plane service request messages) to transmit data (e.g., CIOT data), and reduce overhead by removing unnecessary IEs from the messages. The following table shows an example of the content of a control plane service request message.

[0029] Table 8.2.33.1: Control Plane Service Request Message Content

[0030] According to the scheme proposed in this disclosure, in the context of the new PD, when the UE supports the NAS / AS message overhead reduction function, the UE can use the new PD (e.g., overhead-reduced control plane service request message, overhead-reduced service request message, etc.) to transmit data (e.g., CIOT data). The following table shows an example of the content of the overhead-reduced control plane service request message.

[0031] Table 8.2.xx.yy: Control plane service request message content for reducing overhead

[0032] According to the scheme proposed in this disclosure, in the context of new EMM / EPS Session Management (ESM) in 4G / EPS, a set of new messages (with the same uplink (UL) and downlink (DL) directions) or two sets of new messages (UL and DL) carry user data in an encapsulation format. The message type is a non-standard Layer 3 (L3) message, and the message type can be identified / determined from an IE other than a specific / regular "message type" IE. This means that the message type can be determined, for example, from the security header IE, PD information elements, or key set identifier (KSI) and sequence number IE. The message can carry a short MAC code (e.g., 1, 2, or 3 octets) or a regular-length MAC code (e.g., 4 octets). In the final form, the order of the mandatory (M) information elements in the message (e.g., the octet position of each information element) and their size may differ from the embodiments shown below. In the following examples, a set of new messages or two sets of new messages can be referred to as a new data transfer.

[0033] Message type: New Small Data Transfer

[0034] Importance: Dual

[0035] Direction: Two-way

[0036] Table 8.2.xx.1: New Small Data Transmission Message Content

[0037] The EPS bearer identifier (ID) / PDU session ID / 6G session ID can indicate the data-related session ID. Additionally, the Downlink Data Expected (DDX) can be encoded (e.g., as the DDX field of the Release Auxiliary Information IE in this section). The PD can be an EMM protocol discriminant in idle mode (PD=0 1 1 1) or an ESM protocol discriminant in connected mode (PD=0 0 1 0).

[0038] Message type: New Data Transfer

[0039] Importance: Dual

[0040] Direction: Two-way

[0041] Table 8.2.xx.1: New Data Transmission Message Content

[0042] EPS bearer ID / PDU session ID / 6G session ID can indicate the session ID associated with the data. Similarly, DDX can be encoded (e.g., as the DDX field for the Release Auxiliary Information IE in this section). PD can be an EMM protocol discriminant in idle mode (PD=0 1 1 1) or an ESM protocol discriminant in connected mode (PD=0 0 1 0). For larger data, the length field may need to exceed one octet.

[0043] The table below shows an example of the first option for the security header type.

[0044] Table 9.3.1: Types of Safety Headgear

[0045] The table below shows an example of the second option for the security header type.

[0046] Table 9.3.1: Types of Safety Headgear

[0047] It is worth noting that other encodings and decodings of security header types can also be used to identify message types in the security header (e.g., using additional identifiers to distinguish between UL and DL messages).

[0048] According to the scheme proposed in this disclosure, the integrity of service request (SERVICE REQUEST) or new data transfer (NEW DATA TRANSPORT) messages can be protected using short MAC information elements. Integrity protection may include the first and second octets of the service request or new data transfer message. Only the two least significant octets of the resulting message authentication code are included in the information element. The short MAC information element can be encoded and decoded as follows: The short MAC can be a type 3 information element with a length of 3 octets.

[0049] Figure 9.9.3.28.1: Short MAC Information Elements

[0050] Table 9.9.3.28.1: Short MAC Information Elements

[0051] According to the scheme proposed in this disclosure, in the context of new MM / protocol messages in 5G / 6G, a set of new messages (with the same direction for UL and DL) or two sets of new messages (UL and DL) carry user data in an encapsulation format. The message type is a non-standard L3 message, and the message type can be identified / determined from an IE other than a specific / regular "message type" IE. This means that the message type can be determined, for example, from the security header IE, PD information elements, or KSI and sequence number IE. The message can carry a short MAC code (e.g., 1, 2, or 3 octets) or a regular-length MAC code (e.g., 4 octets). It is worth noting that the new message can also be used as a standalone message to establish a NAS signaling connection as an initial NAS message, and / or carry data in an encrypted / unencrypted format. When used as an initial NAS message, the data payload can be encrypted; otherwise, the message may not be encrypted. In the following examples, a set of new messages or two sets of new messages can be referred to as a new data transfer.

[0052] Message type: New Data Transfer

[0053] Importance: Dual

[0054] Direction: Two-way

[0055] Table 8.2.xx.1: New Small Data Transmission Message Content (Applicable to 5G / 6G)

[0056] The PDU session ID / 6G session ID indicates the session ID associated with the data. Additionally, DDX can be encoded (e.g., as the DDX field for the Release Auxiliary Information IE in this section). The Extended Protocol Discriminator (EPD) can be a 5GMM message type. If the MAC size needs to be a standard 4 octets, then the "Short MAC" (2 octets) can be replaced with a "Message Authentication Code" size of 4 octets.

[0057] Table 8.2.xx.2: New Data Transmission Message Content (Applicable to 5G / 6G)

[0058] The PDU session ID / 6G session ID indicates the session ID associated with the data. Similarly, DDX can be encoded (e.g., as the DDX field for the Release Auxiliary Information IE in this section). EPD can be a 5GMM / 6GMM message type and can be sent in either idle or connected mode. If the MAC size needs to be a standard 4 octets, then the "Short MAC" (2 octets) can be replaced with a "Message Authentication Code" size of 4 octets.

[0059] According to the scheme proposed in this disclosure, in the context of packaging CP data into NAS messages, setting initial and non-initial messages for CP data transmission allows the use of different message structures in different use cases (e.g., initial messages in idle mode or non-initial messages in connected mode) to reduce message header overhead. According to the proposed scheme, a security header type or protocol discriminant can be used to identify whether a message is an initial NAS message and / or a non-initial NAS message. For example, an initial message may include a KSI (3 bits) and / or a sequence number (5 bits). Furthermore, a non-initial message may include a KSI, but with a larger sequence number (8 bits). The message may include information defining the data type being transmitted and other data type-related information. Additionally, the message may include a data container that contains only data or contains data and additional data-type-specific information.

[0060] The following example shows the encoding and decoding method for CP data transmission of the initial message.

[0061] Message type: CP Data Transfer Initial

[0062] Importance: Dual

[0063] Direction: UE to network

[0064] Table 8.2.x1.1: Initial Message Content of CP Data Transmission

[0065] The following example shows the encoding and decoding of CP data transmission for non-initial messages.

[0066] Message type: CP data transmission non-initial

[0067] Importance: Dual

[0068] Direction: Two-way

[0069] Table 8.2.x2.1: Non-initial message content for CP data transmission

[0070] According to the proposed scheme in this disclosure, regarding the security header type, bits 5 through 8 of the first octet of each EMM message may contain the security header type IE. This information element may contain control information related to the security protection of NAS messages. The total size of the security header type information element may be 4 bits. The security header type information element may take the values ​​shown in the examples in the table below.

[0071] Table 9.3.1: Types of Safety Headgear

[0072] When an EMM message with a security header type encoding of 0000 is received, it can be treated as an unprotected ordinary NAS message. When a protocol entity sends an unprotected EMM message, it can send the message as an ordinary NAS message and encode the security header type as 0000.

[0073] According to the proposed scheme, data type information elements can be encoded and decoded as shown in the following example.

[0074]

[0075] Figure 9.9.3.x1.1: Information elements such as data type; the data type is "Control Plane User Data".

[0076] Figure 9.9.3.x1.2: Information elements such as data type; the data type is "Location Service Data".

[0077] Figure 9.9.3.x1.3: Information elements such as data type, where the data type is "SMS".

[0078] CIoT data container information elements can be encoded and decoded as shown in the following examples.

[0079]

[0080] Figure 9.9.3.x2.1: Contents of the CIoT data container, data type is "Control Plane User Data" or "SMS"

[0081] Figure 9.9.3.x2.2: Content of the CIoT data container, data type is "Location Service"

[0082] Example Implementation

[0083] Figure 2 An example communication system 200 is shown according to embodiments of this disclosure, having at least one example device 210 and one example device 220. Each of devices 210 and 220 is capable of performing various functions to implement the schemes, techniques, processes, and methods described herein, relating to NAS protocol header optimization in mobile communications, including the schemes described above regarding various proposed designs, concepts, schemes, systems, and methods, including network environment 100, and the processes described below.

[0084] Each device 210 and device 220 may be part of an electronic device, which may be a network device or UE (e.g., UE 110), such as a portable or mobile device, a wearable device, an in-vehicle device or vehicle, a wireless communication device, or a computing device. For example, each device 210 and device 220 may be implemented in a smartphone, smartwatch, personal digital assistant, electronic control unit (ECU) in a vehicle, digital camera, or computing device such as a tablet, laptop, or mobile phone. Each device 210 and device 220 may also be part of a machine-type device, which may be an IoT device, such as a non-movable or fixed device, a home device, a roadside unit (RSU), a wired communication device, or a computing device. For example, each device 210 and device 220 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. When implemented in or as a network device, device 210 and / or device 220 may be implemented in an eNB in ​​an LTE, LTE-Advanced, or LTE-Advanced Pro network, or in a gNB or TRP in a 5G, NR, or IoT network.

[0085] In some embodiments, each device 210 and device 220 may be one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more complex instruction-set computing (CISC) processors, or one or more reduced instruction-set computing (RISC) processors. In the various embodiments described above, each device 210 and device 220 may be implemented in or as a network device or user equipment. Each device 210 and device 220 may include... Figure 2 The components shown include, for example, processors 212 and 222, respectively. Each device 210 and device 220 may also include one or more other components unrelated to the solutions presented in this disclosure (e.g., internal power supply, display device, and / or user interface device); therefore, for the sake of brevity, Figure 2 These components are not shown in the text and are not described below.

[0086] In one aspect, each processor 212 and processor 222 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more CISC or RISC processors. That is, although the singular term "processor" is used herein to refer to processor 212 and processor 222, each processor 212 and processor 222 may include multiple processors according to certain embodiments of this disclosure, and may include a single processor in other embodiments. In another aspect, each processor 212 and processor 222 may be implemented in hardware (and optionally firmware) and include electronic components such as, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more varactor diodes, configured and arranged according to the specific purposes of this disclosure. In other words, in at least some embodiments, each processor 212 and processor 222 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks, including tasks related to NAS protocol header optimization in mobile communications, according to various embodiments of this disclosure.

[0087] In some embodiments, device 210 may further include a transceiver 216 coupled to processor 212. Transceiver 216 is capable of wirelessly transmitting and receiving data. In some embodiments, transceiver 216 is capable of wireless communication with different types of wireless networks employing different radio access technologies (RATs). In some embodiments, transceiver 216 may be equipped with multiple antenna ports (not shown), such as four antenna ports. That is, transceiver 216 may be equipped with multiple transmit antennas and multiple receive antennas for multiple-input multiple-output (MIMO) wireless communication. In some embodiments, device 220 may further include a transceiver 226 coupled to processor 222. Transceiver 226 may include a transceiver capable of wirelessly transmitting and receiving data. In some embodiments, transceiver 226 is capable of wireless communication with different types of user equipment / wireless networks employing different RATs. In some embodiments, transceiver 226 may be equipped with multiple antenna ports (not shown), such as four antenna ports. In other words, transceiver 226 can be equipped with multiple transmit antennas and multiple receive antennas for MIMO wireless communication.

[0088] In some embodiments, device 210 may further include a memory 214 coupled to processor 212 and capable of being accessed by processor 212 and storing data. In some embodiments, device 220 may further include a memory 224 coupled to processor 222 and capable of being accessed by processor 222 and storing data. Each of memory 214 and memory 224 may include a random-access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitor RAM (Z-RAM). Alternatively, or additionally, each of memory 214 and memory 224 may include a read-only memory (ROM), such as a mask ROM, programmable ROM (PROM), erasable programmable ROM (EPROM), and / or electrically erasable programmable ROM (EEPROM). Alternatively, or additionally, each of memory 214 and memory 224 may include a non-volatile random-access memory (NVRAM), such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and / or phase-change memory.

[0089] Each device 210 and device 220 may be a communication entity capable of communicating with each other according to various proposed schemes of this disclosure. For illustrative purposes and without limitation, the following describes the capabilities of device 210 as a UE (e.g., UE 110) and device 220 as a network node (e.g., network node 125) of a network (e.g., a wireless network 120 as a 5G / NR mobile network) in the context of example flows 300 and 400.

[0090] Example Process

[0091] Figure 3An example flow 300 according to an embodiment of this disclosure is illustrated. Flow 300 may represent one aspect of implementing the various designs, concepts, schemes, systems, and methods proposed above. More specifically, flow 300 may represent one aspect of the concepts and schemes proposed in this disclosure regarding NAS protocol header optimization in mobile communications. Flow 300 may include one or more operations, actions, or functions, as shown in one or more modules. Although shown as discrete modules, the various modules of flow 300 may be divided into more modules, merged into fewer modules, or omitted depending on the desired implementation. Furthermore, the modules / submodules of flow 300 may be arranged according to... Figure 3 The process can be executed in the order shown, or optionally in a different order. Furthermore, one or more modules / submodules of process 300 can be executed repeatedly or iteratively. Process 300 can be implemented by or in devices 210 and 220, and any variations thereof. For illustrative purposes only and without limitation, process 300 is described below in the context of device 210 as a UE (e.g., UE 110) and device 220 as a network node (e.g., non-terrestrial network node 128 or terrestrial network node 125) of a communication entity (e.g., a network (e.g., wireless network 120)). Process 300 may begin in module 310.

[0092] At 310, process 300 may involve the processor 212 of device 210 (as a UE (e.g., UE 110)) communicating with a network (e.g., a wireless network 120 via device 220 as a non-terrestrial network node 128 or a terrestrial network node 125) via transceiver 216, involving support for reduced NAS or AS message overhead for CP data transmission. Process 300 may continue from 310 to 320.

[0093] At 320, process 300 may involve processor 212, in response to both the UE and the network indicating support for the overhead reduction for the CP data transmission, transmitting the CP data with the network via transceiver 216, using a new message with reduced overhead in the NAS protocol header.

[0094] In some implementations, during communication, process 300 may involve processor 212 sending new or existing bits in the IE of the MM to indicate the UE's support for reduced NAS or AS message overhead. In some implementations, the MM may include a 6GMM, 5GMM, or EMM. In some implementations, the message may include a registration request message, a service request message, or an attach request message.

[0095] In some implementations, the new message may include a security header type (IE) and a protocol discriminant. Furthermore, the message type may be indicated by either or both of the security header type (IE) and the protocol discriminant. In some implementations, the message type may be indicated by a combination of the security header type (IE) and the protocol discriminant.

[0096] In some implementations, during communication, process 300 may involve processor 212 receiving new or existing bits from the network in the IE of a message to indicate the network's support for reduced overhead of the NAS or AS message. In some implementations, the message may include a registration accept message, a service accept message, a configuration update command message, or an attach accept message. In some implementations, the new message may include a non-standard L3 message, and the message type of the new message is indicated in an IE other than the message type IE (e.g., by a combination of the security header type IE and the protocol discriminant). In some implementations, the message may include an AS message, such as an RRC connection or reconfiguration message, or an existing or new SIB.

[0097] In some implementations, during the CP data transmission, process 300 may involve processor 212 using NAS or AS messages for the CP data transmission to reduce overhead by: (a) responding to an instruction received via the MO configuration mechanism; or (b) based on information stored in the USIM associated with the UE.

[0098] Figure 4 An example flow 400 according to an embodiment of this disclosure is illustrated. Flow 400 may represent one aspect of implementing the various designs, concepts, schemes, systems, and methods proposed above. More specifically, flow 400 may represent one aspect of the concepts and schemes proposed in this disclosure regarding NAS protocol header optimization in mobile communications. Flow 400 may include one or more operations, actions, or functions, as shown in one or more modules. Although shown as discrete modules, the various modules of flow 400 may be divided into more modules, merged into fewer modules, or omitted depending on the desired implementation. Furthermore, the modules / submodules of flow 400 may be arranged according to... Figure 4 The process can be executed in the order shown, or optionally in a different order. Furthermore, one or more modules / submodules of process 400 can be executed repeatedly or iteratively. Process 400 can be implemented by or in devices 210 and 220, and any variations thereof. For illustrative purposes only and without limitation, process 400 is described below in the context of device 210 as a UE (e.g., UE 110) and device 220 as a network node (e.g., non-terrestrial network node 128 or terrestrial network node 125) of a communication entity (e.g., a network (e.g., wireless network 120)). Process 400 may begin in module 410.

[0099] At 410, process 400 may involve the processor 222 of device 220 (as a network node (e.g., non-terrestrial network node 128 or terrestrial network node 125) of a network (e.g., wireless network 120) communicating with the UE (e.g., device 210) via transceiver 226, involving support for reduced NAS or AS message overhead for CP data transmission. Process 400 may continue from 410 to 420.

[0100] At 420, process 400 may involve processor 222, in response to both the UE and the network indicating support for the overhead reduction for the CP data transmission, transmitting the CP data with the UE via transceiver 226, using a new message with reduced overhead in the NAS protocol header.

[0101] In some implementations, during communication, process 400 may involve processor 222 receiving new or existing bits from a message in the IE of the UE in the MM to indicate the UE's support for reduced NAS or AS message overhead. In some implementations, the MM may include a 6GMM, 5GMM, or EMM. In some implementations, the message may include a registration request message, a service request message, or an attach request message.

[0102] In some implementations, the new message may include a security header type IE and a protocol discriminant. Furthermore, the message type may be indicated by either or both of the security header type IE and the protocol discriminant (e.g., by a combination of the security header type IE and the protocol discriminant).

[0103] In some implementations, during communication, process 400 may involve processor 222 sending new or existing bits to the UE in an IE of a message to indicate network support for NAS or AS message overhead reduction signaling features. In some implementations, the message may include a registration accept message, a service accept message, a configuration update command message, or an attach accept message. In some implementations, the message may include an AS message, such as an RRC connection or reconfiguration message, or an existing or new SIB.

[0104] In some implementations, the new message may be a non-standard LE message, and the message type of the new message may be indicated in an IE other than the message type IE.

[0105] Additional notes

[0106] The topics described herein sometimes demonstrate different components contained within or connected to other different components. It should be understood that such architectures are merely examples, and many other architectures can actually be implemented to achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined in this document to achieve a specific function can be considered “associated with each other” to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to achieve the desired function. Specific examples of being operablely coupled include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive and / or logically interactive components.

[0107] Furthermore, regarding the use of almost all plural and / or singular terms in this document, those skilled in the art can appropriately convert plural to singular and / or singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0108] Furthermore, those skilled in the art will understand that the terms used herein, particularly in appended claims, such as the body portion of appended claims, are generally intended as “open” terms. For example, “comprising” should be interpreted as “including but not limited to,” “having” should be interpreted as “having at least,” “including” should be interpreted as “including but not limited to,” and so on. Those skilled in the art will also understand that if a claim intends to introduce a particular quantity, that intention will be explicitly stated in the claim, and if no such statement is made, that intention does not exist. For example, for ease of understanding, the phrases “at least one” and “one or more” may be included in the appended claims to introduce the recitation of the claim. However, the use of such phrases should not be construed as limiting any particular claim containing such a statement to containing only one such statement, even if the same claim contains the phrases “one or more” or “at least one” and indefinite articles such as “a” or “one,” for example, “a” and / or “one” should be interpreted as “at least one” or “one or more”; the same applies to definite articles used to introduce the recitation of the claim. Furthermore, even if a specific quantity is explicitly stated in the claims, those skilled in the art will recognize that this statement should be interpreted as at least the stated quantity. For example, the single statement "two items" without other modifications means at least two items, or two or more items. Additionally, when using conventions such as "at least one of A, B, and C," this structure is generally intended to convey the meaning understood by those skilled in the art. For example, "a system having at least one of A, B, and C" includes, but is not limited to, systems with only A, only B, only C, A and B, A and C, B and C, and systems where A, B, and C coexist. Those skilled in the art will also understand that almost all disjunctive terms and / or phrases appearing in the specification, claims, or drawings, when presenting two or more alternative terms, should be understood to include one, any, or both terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B”.

[0109] As can be seen from the foregoing, various embodiments of this disclosure have been described herein for illustrative purposes, and various modifications may be made without departing from the scope and spirit of this disclosure. Therefore, the various embodiments disclosed herein are not intended to be limiting, and the true scope and spirit are indicated by the following claims.

Claims

1. A method, comprising: The communication between the user equipment's processor and the network involves support for reducing the overhead of non-access stratum or access stratum messages for control plane data transmission; as well as In response to both the user equipment and the network indicating support for the reduced overhead for the control plane data transmission, the processor performs the control plane data transmission with the network using a new message with reduced overhead in the non-access stratum protocol header.

2. The method of claim 1, wherein communicating comprises sending new or existing bits in the mobility management information element of the network to indicate the user equipment's support for reduced overhead of the non-access stratum or access stratum message, and wherein the message includes a registration request message, a service request message, or an attach request message.

3. The method of claim 2, wherein the mobility management includes sixth-generation mobility management, fifth-generation mobility management, or evolved packet system mobility management.

4. The method of claim 1, wherein the new message includes a security header type information element and a protocol discriminant, and the message type is indicated by either or both of the security header type information element and the protocol discriminant.

5. The method of claim 1, wherein communicating includes receiving new or existing bits from the network in information elements of a message to indicate the network's support for reduced overhead of the non-access stratum or access stratum message, and wherein the message includes a registration acceptance message, a service acceptance message, a configuration update command message, or an attach acceptance message.

6. The method of claim 1, wherein the new message is a non-standard Level 3 message, and the message type of the new message is indicated in an information element other than the message type information element.

7. The method of claim 5, wherein the message includes an access layer message.

8. The method of claim 7, wherein the access layer message includes a radio resource control connection or reconfiguration message, or an existing or new system information block.

9. The method of claim 1, wherein performing the control plane data transmission includes using non-access stratum or access stratum messages for the control plane data transmission to reduce overhead, in the following manner: In response to receiving an instruction through the managed object configuration mechanism; or Based on the information stored in the generic user identity module associated with the user equipment.

10. A method comprising: The communication between the network node's processor and the user equipment involves support for reducing the overhead of non-access stratum or access stratum messages for control plane data transmission; as well as In response to both the user equipment and the network indicating support for the reduced overhead for the control plane data transmission, the processor performs the control plane data transmission with the user equipment using a new message with reduced overhead in the non-access stratum protocol header.

11. The method of claim 10, wherein communicating includes receiving new or existing bits from a message in a mobility management information element of the user equipment to indicate the user equipment's support for reduced overhead of the non-access stratum or access stratum message, and wherein the message includes a registration request message, a service request message, or an attach request message.

12. The method of claim 11, wherein the mobility management includes sixth-generation mobility management, fifth-generation mobility management, or evolved packet system mobility management.

13. The method of claim 10, wherein the new message includes a security header type information element and a protocol discriminant, and the message type is indicated by either or both of the security header type information element and the protocol discriminant.

14. The method of claim 10, wherein communicating includes sending new or existing bits to the user equipment in an information element of a message to indicate the network's support for reduced overhead of the non-access stratum or access stratum message, and wherein the message includes a registration acceptance message, a service acceptance message, a configuration update command message, or an attach acceptance message.

15. The method of claim 10, wherein the new message is a non-standard Level 3 message, and the message type of the new message is indicated in an information element other than the message type information element.

16. The method of claim 14, wherein the message includes an access layer message.

17. The method of claim 16, wherein the access layer message includes a radio resource control connection or reconfiguration message, or an existing or new system information block.

18. An apparatus that can be implemented in a user equipment, comprising: A transceiver configured for wireless communication; as well as A processor, coupled to and configured to perform operations on the transceiver, including: Communicating with the network via this transceiver involves support for reducing the overhead of non-access stratum or access stratum messages in control plane data transmission; as well as In response to both the user equipment and the network indicating support for the reduced overhead for control plane data transmission, the control plane data transmission with the network via the transceiver employs a new message with reduced overhead in the non-access stratum protocol header.

19. The apparatus of claim 18, wherein communicating includes transmitting new or existing bits to the network in a mobility management information element in a message to indicate the user equipment's support for the non-access stratum or access stratum message overhead reduction signaling function, wherein the mobility management includes sixth-generation mobility management, fifth-generation mobility management, or evolved packet system mobility management, and the message includes a registration request message, a service request message, or an attach request message.

20. The apparatus of claim 18, wherein communicating includes receiving new or existing bits from information elements in a message from the network to indicate the network's support for the non-access stratum or access stratum message overhead reduction signaling function, and the message includes a registration acceptance message, a service acceptance message, a configuration update command message, or an attach acceptance message.

Images