Method and equipment for exchanging manufacturer identification

Abstract

The invention provides a method and equipment for exchanging a manufacturer identifier, and the method for exchanging the manufacturer identifier comprises the following steps: a processor of user equipment (UE) exchanges manufacturer information with a network, and the manufacturer information comprises one or two of the following: a manufacturer identifier (ID); and a manufacturer version. According to the invention, communication can be carried out better.

Description

TECHNICAL FIELD

[0001] The present invention relates generally to mobile communications, and more specifically to exchanging vendor identification (ID) in non-access stratum (NAS) and radio resource control (RRC) messages of mobile communications. BACKGROUND

[0002] In wireless communications (e.g., mobile communications) under current 3GPP specifications, with respect to user equipment (UE) information request and response, a network can send a UE information request to a UE to query for certain information. The UE can reply with a UE information response to return the corresponding information of the UE. On the other hand, there have been some proprietary implementations to convey UE / infrastructure vendor ID. Knowing the UE vendor ID from the infrastructure vendor or the infrastructure vendor ID from the UE vendor can facilitate optimization of certain vendor-dependent procedures in the UE and the infrastructure.

[0003] However, at the time of the present invention, there is no standardized method to convey the UE / infrastructure vendor ID. In particular, proprietary signaling methods can not be robust enough. For example, a proprietary method can assume that certain values or information elements (IEs) will not be used in the future. This assumption is not guaranteed at all. Furthermore, if there are some changes to the information, it would be very difficult to manage such changes that can be compatible between multiple product versions. Also, when an unsupported receiver receives such proprietary information, its behavior can not be well-defined. Therefore, there is a need for a solution to exchange vendor ID in non-access stratum and radio resource control messages in mobile communications. SUMMARY

[0004] The following summary is illustrative only and is not intended to be limiting in any way. In other words, the following summary is provided to introduce some concepts, facets, benefits and advantages of the novel and non-obvious technology described herein. Selected implementations are described in further detail in the detailed description. As such, the following summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in determining the scope of the claimed subject matter.

[0005] An embodiment of the present invention provides a method of exchanging vendor identification, comprising: exchanging, by a processor of a user equipment (UE), vendor information with a network, wherein the vendor information comprises one or both of: a vendor identification (ID); and a vendor version.

[0006] An embodiment of the present invention provides a method of exchanging vendor identification, comprising: exchanging, by a processor of a network node, vendor information with a user equipment (UE), wherein the vendor information comprises one or both of: a vendor ID; and a vendor version.

[0007] An apparatus for exchanging vendor identification, comprising a transceiver for wireless communication; and a processor coupled to the transceiver for performing operations including exchanging network vendor information, wherein the vendor information includes one or both of: a vendor identification ID; and a vendor version.

[0008] It is noted that while the description provided herein can be in the context of certain radio access technologies, networks, and network topologies, such as LTE, LTE-Advanced, LTE-Advanced Pro, 5G, NR, IoT, NB-IoT, IIoT, B5G, and 6G, the concepts, schemes, and any variations / derivatives thereof presented can be implemented in other types of radio access technologies, networks, and network topologies, for other types of radio access technologies, networks, and network topologies, and by other types of radio access technologies, networks, and network topologies. Thus, the scope of the present application is not limited to the examples described herein. BRIEF DESCRIPTION OF DRAWINGS

[0009] The accompanying drawings are included to provide a further understanding of principles of the application and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the application and, together with the description, serve to explain principles of the application. It is noted that the drawings may not be to scale as certain components can be shown exaggerated in scale or with their sizes reversed for the sake of clarity in illustrating the concepts of the application.

[0010] Figure 1 is an example network environment in accordance with an embodiment of the application.

[0011] Figure 2 is an example design in accordance with an embodiment of the application.

[0012] Figure 3 is an example design in accordance with an embodiment of the application.

[0013] Figure 4 is an example design in accordance with an embodiment of the application.

[0014] Figure 5 is an example design in accordance with an embodiment of the application.

[0015] Figure 6 is an example design in accordance with an embodiment of the application.

[0016] Figure 7 is an example design in accordance with an embodiment of the application.

[0017] Figure 8 is an example communication system in accordance with an embodiment of the application.

[0018] Figure 9is an example process according to an embodiment of the application.

[0019] Figure 10 is an example process according to an embodiment of the application. DETAILED DESCRIPTION

[0020] Detailed embodiments and implementations of the claimed subject matter are disclosed. It should be understood, however, that the embodiments and implementations disclosed are merely illustrative of the claimed subject matter that can be implemented in various forms. Furthermore, the present application can be implemented in 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 so that this disclosure will be thorough and complete, and fully convey the scope of the application to those skilled in the art. In the following description, details of known features and techniques can be omitted in order not to unnecessarily obscure the presented embodiments and implementations.

[0021] SUMMARY

[0022] Embodiments of the present application relate to various techniques, methods, schemes and / or solutions related to exchanging vendor ID in mobile communications via NAS and RRC messages. According to the present application, a number of possible schemes can be implemented separately or jointly. That is, while these possible solutions can be described separately below, two or more of these possible solutions can be implemented in a combination or other combination manner.

[0023] Figure 1 is an example network environment 100 according to an embodiment of the application. Figures 2 to 10 is an example of implementing various proposed schemes in network environment 100 according to an embodiment of the application. The following description of various proposed schemes is with reference to Figures 1 to 10 provided.

[0024] Reference Figure 1The network environment 100 involves a UE 110 (wirelessly communicating with a wireless network 120 (e.g., a 6G mobile network containing an NTN and a TN) through a terrestrial network node 125 (e.g., an evolved Node B (eNB), a next generation Node B (gNB), or a transmission / reception point (TRP)) and / or a non-terrestrial network node 128 (e.g., a satellite). For example, the terrestrial network node 125 and / or the non-terrestrial network node 128 can form a non-terrestrial network (NTN) serving cell to wirelessly communicate with the UE 110. In some embodiments, the UE 110 can be a smartphone, a wearable device, an Internet of Things device, such as a 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, the UE 110, the network 120, the terrestrial network node 125, and the non-terrestrial network node 128 can implement various schemes for vendor ID exchange in NAS and RRC messages as described below in relation to the present disclosure.

[0025] It is worth noting that while various proposed schemes can be described below separately or individually, some or all of the proposed schemes can be used or implemented jointly in practice. Of course, each proposed scheme can be used or implemented separately or individually. Further, in the present disclosure, a non-access stratum (NAS) layer can refer to a layer in a 5G protocol stack that is above a radio resource control (RRC) layer, above a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a medium access control (MAC) layer, a physical (PHY) layer, and the like.

[0026] Figure 2 is an example design 200 according to an embodiment of the present disclosure. Under the proposed scheme, some RRC messages can be used to convey infrastructure (e.g., radio network node) vendor information, while some RRC messages can be used to convey UE vendor information. In the design 200, a network (NW) can use a UE information request message (UEInformationRequest) to convey or provide infrastructure vendor information (gnbVendorInfo) to a UE. Correspondingly, the UE can use a UE information response message (UEInformationResponse) to convey or provide vendor information (ueVendorInfo) to the network. Under the proposed scheme, the vendor information (e.g., in a vendor information IE) can include one or two fields, namely: a vendor ID and an optional vendor version (which can be a hardware and software combined version or a pure software version).

[0027] Figure 3is an example design 300 according to embodiments of the application. Under the proposed scheme, some RRC messages can be used to convey infrastructure (e.g., radio network node) vendor information, while some RRC messages can be used to convey UE vendor information. In design 300, the network can use the RRC Reconfiguration message (RRCReconfiguration) to convey or provide infrastructure vendor information to the UE. Correspondingly, the UE can use the RRC Reconfiguration Complete message (RRCReconfigurationComplete) to convey or provide vendor information to the network. Under the proposed scheme, the vendor information (e.g., in the Vendor Information IE) can include one or two fields, namely: Vendor ID and optionally Vendor Version (which can be a hardware and software combined version or a pure software version).

[0028] Figure 4 is an example design 400 according to embodiments of the application. Design 400 can involve an example of at least part of the content of the UE Information Request message (shown as UE information Request in the figure) and the UE Information Response message (shown as UE information Response in the figure) used in design 200.

[0029] Figure 5 is an example design 500 according to embodiments of the application. Design 500 can involve an example of at least part of the content of the RRC Reconfiguration message (shown as RRC Reconfiguration in the figure) and the RRC Reconfiguration Complete message (shown as RRCReconfiguration Complete in the figure) used in design 300.

[0030] Figure 6is an example design 600 according to embodiments of the application. In the proposed approach, some NAS messages can be used to convey UE vendor information, while some NAS messages can be used to convey core network vendor information. In the design 600, a registration request message can be used by a UE to convey or provide UE vendor information to a network. In addition, a registration accept message can be used by a network to convey or provide core network vendor information (cnVendorlnfo) to a UE. In the proposed approach, the vendor information can be sent through security protected messages (e.g., ciphering and integrity protection) to avoid information leakage. For example, UE information request / response messages, as well as RRC reconfiguration and RRC reconfiguration complete messages, can be used as security protected messages. In addition, the registration request / accept messages can be transmitted in clear text, and thus the UE and the network can need to wait until a NAS security mode complete message is completed before transmission if no NAS security context is established in the first registration request / accept message.

[0031] Figure 7 is an example design according to embodiments of the application. The design 700 can involve examples of at least part of the content of the registration request message (shown as registration request in the figure) and the registration accept message (shown as registration accept in the figure) used in the design 600.

[0032] In view of the above, according to various proposed approaches of the application, a method of exchanging vendor information in a wireless communication network (e.g., the network 120) can involve a UE (e.g., the UE 110) transmitting UE vendor information to a network node (e.g., the ground network node 125 or the non-ground network node 128) by using a NAS message, and / or receiving core network node vendor information from the network node by the UE. The vendor information can include at least one of (i) a vendor identity / identification, and (ii) a vendor software version or a combination of software and hardware versions.

[0033] In addition, according to various proposed approaches of the application, a method of exchanging vendor information in a wireless communication network (e.g., the network 120) can involve a UE (e.g., the UE 110) receiving radio network node vendor information from a network node (e.g., the ground network node 125 or the non-ground network node 128) by using a RRC message, and / or replying UE vendor information to the network node by the UE. The vendor information can include at least one of (i) a vendor identity / identification, and (ii) a vendor software version or a combination of software and hardware versions.

[0034] Illustrative Implementations

[0035] Figure 8 This is an example communication system 800 according to an embodiment of the present invention, which includes at least example device 810 and example device 820. Each of device 810 and device 820 can perform various functions to implement the schemes, techniques, processes and methods described herein for exchanging vendor IDs via NAS and RRC messages in mobile communications, including the foregoing description of various proposed designs, concepts, schemes, systems and methods, including network environment 100 and the processes described below.

[0036] Each of devices 810 and 820 can be part of an electronic device, which can be a network device or UE (e.g., UE 110), such as a portable or mobile device, wearable device, in-vehicle device or vehicle, wireless communication device, or computing device. For example, each of devices 810 and 820 can 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 notebook computer. Each of devices 810 and 820 can also be part of a machine-type device, which can be an Internet of Things (IoT) device, such as a non-movable or fixed device, home appliance, roadside unit (RSU), wired communication device, or computing device. For example, each of devices 810 and 820 can be implemented in a smart thermostat, smart refrigerator, smart door lock, wireless speaker, or home control center. When implemented in or as a network device, device 810 and / or device 820 may be implemented in an eNB in ​​an LTE, LTE Advanced, LTE Advanced Pro, or IoT network, or in a gNB or TRP in a 5G / 6G or IoT network.

[0037] In some embodiments, each of devices 810 and 820 may be implemented as 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 of devices 810 and 820 may be implemented as a network device or a UE. Each of devices 810 and 820 may include... Figure 8 At least some components are shown, such as processor 812 and processor 822. Each of devices 810 and 820 may also include one or more other components unrelated to the proposed embodiments of the present invention (e.g., internal power supply, display device, and / or user interface device), but for simplicity and brevity, these components are not shown. Figure 8 This is shown in the text and not described in the following text.

[0038] On the one hand, each of processors 812 and 822 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more Complex Instruction Set Computing (CISC) or Reduced Instruction Set Computing (RISC) processors. That is, although the singular term “processor” is used herein to refer to processors 812 and 822, each of processors 812 and 822 may include multiple processors in some implementations of the invention, or may include a single processor in other implementations.

[0039] On the other hand, each of processors 812 and 822 may be implemented in the form of hardware (and optionally, firmware) containing 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 transformers, which are configured and arranged to achieve a specific purpose according to the invention. In other words, in at least some implementations, each of processors 812 and 822 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks, including tasks related to exchanging vendor IDs via NAS and RRC messages in mobile communications according to various implementations of the invention.

[0040] In some implementations, device 810 may also include a transceiver 816 coupled to processor 812. Transceiver 816 can wirelessly transmit and receive data. In some implementations, transceiver 816 can wirelessly communicate with different types of wireless networks using different Radio Access Technologies (RATs). In some implementations, transceiver 816 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. That is, transceiver 816 may be equipped with multiple transmit antennas and multiple receive antennas for multiple-input multiple-output (MIMO) wireless communication.

[0041] In some implementations, device 820 may also include a transceiver 826 coupled to processor 822. Transceiver 826 may include a transceiver capable of wirelessly transmitting and receiving data. In some implementations, transceiver 826 may wirelessly communicate with different RATs of different types of user equipment (UE) / wireless networks. In some implementations, transceiver 826 may be equipped with multiple antenna ports (not shown), for example, four antenna ports. That is, transceiver 826 may be equipped with multiple transmit antennas and multiple receive antennas for MIMO wireless communication.

[0042] In some implementations, device 810 may further include a memory 814 coupled to processor 812, which can be accessed by processor 812 and stores data. In some implementations, device 820 may further include a memory 824 coupled to processor 822, which can be accessed by processor 822 and stores data. Each of memory 814 and memory 824 may include a random access memory (RAM), such as dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and / or zero-capacitance RAM (Z-RAM). Alternatively, or additionally, each of memory 814 and memory 824 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, each of memories 814 and 824 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.

[0043] Each of devices 810 and 820 may be a communication entity capable of communicating with each other using various proposed schemes according to the present invention. For illustrative purposes and without limitation, the following description, within the context of example processes 900 and 1000, describes the capabilities of device 810 as a UE (e.g., UE 110) and device 820 as a network node (e.g., terrestrial network node 125 or non-terrestrial network node 128) of a network (e.g., a wireless network 120 as a 5G / NR mobile network).

[0044] Explanatory process

[0045] Figure 9 This is an example process 900 according to an embodiment of the present invention. Process 900 may represent one aspect of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More specifically, process 900 may represent one aspect of a proposed concept and scheme related to exchanging vendor IDs via NAS and RRC messages in mobile communications according to the present invention. Process 900 may include one or more operations, actions, or functions represented by one or more blocks. Although shown as discrete blocks, the individual blocks of process 900 may be divided into more blocks, merged into fewer blocks, or omitted, depending on the desired implementation. Furthermore, the blocks / sub-blocks of process 900 may be arranged according to... Figure 9The execution may proceed in the order shown, or in a different order. Furthermore, one or more blocks / subblocks of process 900 may be executed repeatedly or iteratively. Process 900 may be implemented by or by devices 810 and 820, and any variations thereof. For illustrative purposes only and without limitation, process 900 is described below in the context of device 810 as a UE (e.g., UE 110) and device 820 as a communication entity (e.g., non-terrestrial network node 128 or terrestrial network node 125). Process 900 may begin with block 910.

[0046] At 910, process 900 may involve the processor 812 of device 810, acting as a UE (e.g., UE 110), exchanging vendor information with a network (e.g., a wireless network 120 via device 820 acting as a terrestrial network node 125 or a non-terrestrial network node 128) via transceiver 816. In some implementations, vendor information may include one or both of the following: (i) vendor ID, and (ii) vendor version.

[0047] In some implementations, a vendor version may include a software version, or a combination of hardware and software versions.

[0048] In some implementations, the exchange of vendor information can be represented by 912 and / or 914. Furthermore, the exchange of vendor information can involve exchanging vendor information using NAS messages.

[0049] At 912, process 900 may involve processor 812 transmitting the UE's vendor information to the network. For example, when transmitting the UE's vendor information, process 900 may involve processor 812 transmitting a registration request message including the UE's vendor information. Process 900 may optionally continue from 912 to 914.

[0050] In step 914, process 900 may involve processor 812 receiving vendor information of core network nodes from the network. For example, when receiving vendor information of core network nodes, process 900 may involve processor 812 receiving a registration acceptance message that includes the vendor information of the core network nodes.

[0051] Alternatively, the exchange of vendor information can be represented by 916 and / or 918. Furthermore, the exchange of vendor information can involve exchanging vendor information using RRC messages.

[0052] In step 916, process 900 may involve processor 812 receiving vendor information of a radio network node from the network. For example, when receiving vendor information of a radio network node, process 900 may involve processor 812 receiving a UE information request message that includes the radio network node vendor information. Alternatively, when receiving vendor information of a radio network node, process 900 may involve processor 812 receiving an RRC reconfiguration message that includes the radio network node vendor information. Process 900 may optionally continue from step 916 to step 918.

[0053] In step 918, process 900 may involve processor 812 transmitting the UE's vendor information to the network. For example, when transmitting the UE's vendor information, process 900 may involve processor 812 transmitting a UE information response message that includes the UE's vendor information. Alternatively, when transmitting the UE's vendor information, process 900 may involve processor 812 transmitting an RRC reconfiguration complete message that includes the UE's vendor information.

[0054] Figure 10 This is an example process 1000 according to an embodiment of the present invention. Process 1000 may represent one aspect of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More specifically, process 1000 may represent one aspect of a proposed concept and scheme related to exchanging vendor IDs via NAS and RRC messages in mobile communications according to the present invention. Process 1000 may include one or more operations, actions, or functions represented by one or more modules. Although represented as discrete modules, the individual modules of process 1000 may be divided into more modules, merged into fewer modules, or omitted, depending on the desired implementation. Furthermore, the modules / submodules of process 1000 may be arranged according to... Figure 10 The execution may proceed in the order shown, or in a different order. Furthermore, one or more modules / submodules of process 1000 may be executed repeatedly or iteratively. Process 1000 may be implemented by or in devices 810 and 820, and any variations thereof. For illustrative purposes only and without limitation, process 1000 is described below in the context of device 810 as a UE (e.g., UE 110) and device 820 as a communication entity of the network (e.g., non-terrestrial network node 128 or terrestrial network node 125). Process 1000 may begin with block 1010.

[0055] In 1010, process 1000 may involve the processor 822 of device 820, which is a network node (e.g., terrestrial network node 125 or non-terrestrial network node 128) of a network (e.g., wireless network 120), exchanging vendor information with the UE (e.g., device 810) via transceiver 826. In some implementations, vendor information may include one or both of the following: (i) vendor ID, and (ii) vendor version.

[0056] In some implementations, a vendor version may include a software version, or a combination of hardware and software versions.

[0057] In some implementations, the exchange of vendor information can be represented by 1012 and / or 1014. Furthermore, the exchange of vendor information can involve exchanging vendor information using NAS messages.

[0058] At 1012, process 1000 may involve processor 822 receiving vendor information of the UE from the UE. For example, when receiving the vendor information of the UE, process 1000 may involve processor 822 receiving a registration request message including the vendor information of the UE. Process 1000 may optionally continue from 1012 to 1014.

[0059] In step 1014, process 1000 may involve processor 822 transmitting vendor information of the core network node to the UE. For example, when transmitting vendor information of the core network node, process 1000 may involve processor 822 transmitting a registration acceptance message that includes the vendor information of the core network node.

[0060] Alternatively, the exchange of vendor information can be represented by 1016 and / or 1018. Furthermore, the exchange of vendor information can involve exchanging vendor information using RRC messages.

[0061] At 1016, process 1000 may involve processor 822 transmitting vendor information of the radio network node to the UE. For example, when transmitting vendor information of the radio network node, process 1000 may involve processor 822 transmitting a UE information request message including the vendor information of the radio network node. Alternatively, when transmitting vendor information of the radio network node, process 1000 may involve processor 822 transmitting an RRC reconfiguration message including the vendor information of the radio network node. Process 1000 may optionally continue from 1016 to 1018.

[0062] In step 1018, process 1000 may involve processor 812 receiving UE vendor information from the UE. For example, when receiving UE vendor information, process 1000 may involve processor 822 receiving a UE information response message that includes the UE vendor information. Alternatively, when receiving UE vendor information, process 1000 may involve processor 822 receiving an RRC reconfiguration complete message that includes the UE vendor information.

[0063] Additional notes

[0064] The subject matter described in this invention sometimes illustrates different components included within or connected to other components. However, it should be understood that these depicted architectures are merely examples, and many other architectures implementing the same functionality can actually be implemented. Conceptually, any arrangement of components implementing the same function is effectively “associated” to enable the desired functionality. Therefore, regardless of architecture or intermediate components, any two components combined in this invention to achieve a specific function can be considered “associated” with each other to enable the desired functionality. Similarly, any two such associated components can also be considered “operationally connected” or “operationally coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operationally coupled” to each other to achieve the desired functionality. Specific examples of operationally coupled components include, but are not limited to, physically mating and / or physically interacting components and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0065] Furthermore, regarding any plural and / or singular terms used substantially in this invention, those skilled in the art can convert them from plural to singular and / or from singular to plural as appropriate for the content and / or application. For clarity, various singular / plural substitutions may be explicitly stated in this invention.

[0066] Furthermore, those skilled in the art will understand that, generally, the terms used in this invention, and especially in the appended claims (e.g., the body of the appended claims), are generally meant as “open-ended” terms. For example, the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” and so on. Those skilled in the art will also understand that if a specific number of claims is intentionally listed, this intention will be explicitly listed in the claims, and the absence of such a listing will not indicate this intention. For example, to aid understanding, the appended claims may include the use of the introductory phrases “at least one” and “one or more.” However, the use of such phrases should not be construed as implying that the introduction of the indefinite article “a” or “an” limits any particular claim that includes such an introductory claim to only one embodiment of such a listing, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an,” for example, “a and / or one” should be interpreted as meaning “at least one” or “one or more,” the same applies to the use of definite articles used to introduce claims. Furthermore, even when a specific number of the introduced claims are explicitly listed, those skilled in the art will recognize that such a listing should be interpreted as meaning at least the number listed. For example, in the absence of other modifiers, the basic listing of "two listings" means at least two listings or two or more listings. Additionally, when using conventions such as "at least one of A, B, and C," it generally means, in the sense that those skilled in the art will understand, that a system having at least one of A, B, and C will include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. When using conventions such as "at least one of A, B, or C," it generally means, in the sense that those skilled in the art will understand, that a system having at least one of A, B, or C will include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. Those skilled in the art will also understand that any transitional words and / or phrases in the specification, claims, or drawings that actually indicate two or more options should be understood to include the possibility of including one, any, or both of these items. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B".

[0067] As can be seen from the foregoing, it is understood that various embodiments of the present invention have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of the invention. Therefore, the various embodiments disclosed in this invention are not intended to be limiting, and the true scope and spirit are determined by the appended claims.

Claims

1. A method of exchanging vendor identities, comprising: exchanging, by a processor of a user equipment (UE), vendor information with a network, wherein the vendor information comprises one or both of: a vendor identity (ID); and a vendor version. The vendor version comprises a software version, or a combination of a hardware and software version.

2. The method for exchanging a vendor identification of claim 1, wherein, exchanging the vendor information comprises:

3. The method for exchanging a vendor identification of claim 1, wherein, transmitting, to the network, the vendor information of the UE; or receiving, from the network, the vendor information of a core network node; or transmitting, to the network, the vendor information of the UE and receiving, from the network, the vendor information of the core network node. Exchanging the vendor information comprises exchanging the vendor information using a non-access stratum (NAS) message.

4. The method for exchanging a vendor identification of claim 3, wherein, 5. The method of exchanging vendor identities of claim 4, wherein: transmitting the vendor information of the UE comprises transmitting a registration request message comprising the vendor information of the UE; and receiving the vendor information of the core network node comprises receiving a registration accept message comprising the vendor information of the core network node. Exchanging the vendor information comprises: receiving, from the network, the vendor information of a radio network node; or 6. The method for exchanging a vendor identification of claim 1, wherein, transmitting, to the network, the vendor information of the UE; or receiving, from the network, the vendor information of the radio network node and transmitting, to the network, the vendor information of the UE. Exchanging the vendor information comprises exchanging the vendor information using a radio resource control (RRC) message.

8. The method of exchanging vendor identities of claim 7, wherein:

7. The method for exchanging a vendor identification of claim 6, wherein, receiving the vendor information of the radio network node comprises receiving a UE information request message comprising the vendor information of the radio network node; and transmitting the vendor information of the UE comprises transmitting a UE information response message comprising the vendor information of the UE.

9. The method of exchanging vendor identities of claim 7, wherein: receiving the vendor information of the radio network node comprises receiving an RRC reconfiguration message comprising the vendor information of the radio network node; and transmitting the vendor information of the UE comprises transmitting an RRC reconfiguration complete message comprising the vendor information of the UE.

10. A method of exchanging vendor identities, comprising: exchanging, by a processor of a network node, vendor information with a UE, wherein the vendor information comprises one or both of: a vendor ID; and a vendor version. The vendor version comprises a software version, or a combination of a hardware and software version. exchanging the vendor information comprises: receiving, from the UE, the vendor information of the UE; or transmitting, to the UE, the vendor information of a core network node; or receiving, from the UE, the vendor information of the UE and transmitting, to the UE, the vendor information of the core network node.

11. The method for exchanging a vendor identification of claim 10, wherein, Exchanging the vendor information comprises exchanging the vendor information using a NAS message.

12. The method for exchanging a vendor identification of claim 10, wherein, receiving the vendor information of the UE comprises receiving a registration request message comprising the vendor information of the UE; and transmitting the vendor information of the core network node comprises transmitting a registration accept message comprising the vendor information of the core network node. Exchanging the vendor information comprises: transmitting, to the UE, the vendor information of a radio network node; or 13. The method for exchanging a vendor identification of claim 12, wherein, receiving, from the UE, the vendor information of the UE; or 14. The method for exchanging a vendor identification of claim 13, transmitting, to the UE, the vendor information of the radio network node and receiving, from the UE, the vendor information of the UE. ​ ​ ​ 15. The method for exchanging a vendor identification of claim 10, wherein, ​ ​ ​ ​ 16. The method for exchanging a vendor identification of claim 15, wherein, Exchanging the vendor information includes exchanging the vendor information using RRC messages.

17. The method of exchanging vendor identities of claim 16, wherein: transmitting the vendor information of the radio network node includes transmitting a UE information request message including the vendor information of the radio network node; and receiving the vendor information of the UE includes receiving a UE information response message including the vendor information of the UE.

18. The method of exchanging vendor identities of claim 16, wherein: transmitting the vendor information of the radio network node includes transmitting a RRC reconfiguration message including the vendor information of the radio network node; and receiving the vendor information of the UE includes receiving a RRC reconfiguration complete message including the vendor information of the UE.

19. An apparatus for exchanging vendor identities, comprising: a transceiver for wireless communication; and a processor coupled to the transceiver for performing operations including exchanging vendor information with a network, wherein the vendor information includes one or both of: a vendor identity ID; and a vendor version. The vendor version includes a software version, or a combination of a hardware and software version.

20. The device of claim 19, wherein the exchange of the vendor identification is performed by a vendor identification exchange module. ​

Images