RDS protocol for long application identifiers

Abstract

A computer-readable storage medium storing instructions for execution by one or more processors of a UE is disclosed. The instructions configure the UE as an initiator UE in a CIOT system for RDS communication and cause the UE to perform operations including encoding a Manage_Port command for transmission to a receiver UE. The Manage_Port command includes a query for availability of a plurality of destination ports of the receiver UE. A Manage_Port response from the receiver UE is decoded. The Manage_Port response includes, for each destination port in a subset of the plurality of destination ports: a destination port number, a source port number of a source port of the initiator UE paired with the destination port, and an application ID of an application executing on the initiator UE. Data associated with the application is encoded for RDS communication between the source port and the destination port.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 066,765, filed August 17, 2020, entitled “Updated RDS Protocol for Long Application Identifiers”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] Various aspects involve wireless communications. Some aspects involve wireless networks, including 3GPP (3rd Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, 3GPP LTE-A (LTE Advanced) networks, (MulteFire, LTE-U), and fifth-generation (5G) networks (including 5G New Radio (NR) (or 5G-NR) networks, 5G-LTE networks, such as 5G NR Unlicensed Spectrum (NR-U) networks), and other unlicensed networks (including Wi-Fi, CBRS (OnGo), etc.). Other aspects involve Reliable Data Service (RDS) protocol configuration, including RDS protocols for long application identifiers. Background Technology

[0004] Mobile communications have evolved significantly from early voice systems to today's highly complex integrated communication platforms. The use of 3GPP LTE systems has increased along with the growing number of different types of devices communicating with various network devices. The proliferation of mobile devices (User Equipment) in modern society continues to drive demand for a wide range of connected devices in many different environments. Fifth-generation (5G) wireless systems are on the horizon and promise higher speeds, connectivity, and availability. The next generation of 5G networks (or NR networks) promises improved throughput, coverage, and robustness, while reducing latency and operating and capital expenditures. 5G-NR networks will continue to evolve based on 3GPP LTE Advanced, adding more potential new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions that deliver fast, rich content, and services. Because current cellular network frequencies are already saturated, higher frequencies (e.g., millimeter wave (mmWave) frequencies) can be beneficial due to their higher bandwidth.

[0005] Potential LTE operations in unlicensed spectrum include (but are not limited to) LTE operations via dual connectivity (DC), or via DC-based LAA, and via a standalone LTE system in unlicensed spectrum, where LTE-based technologies operate solely in the unlicensed spectrum without requiring an "anchor" in the licensed spectrum, known as MulteFire. MulteFire combines the performance advantages of LTE technology with the simplicity of Wi-Fi-like deployment.

[0006] Future versions and 5G systems are expected to further enhance the operation of LTE and NR systems in both licensed and unlicensed spectrum. This enhanced operation may include techniques for configuring the RDS protocol for long application identifiers. Attached Figure Description

[0007] In accompanying drawings that are not necessarily drawn to scale, similar reference numerals may describe similar components in different views. Similar reference numerals with different letter suffixes may indicate different instances of similar components. The accompanying drawings are illustrated in an exemplary rather than restrictive manner, summarizing the various aspects discussed in this document.

[0008] Figure 1A The architecture of the network is shown based on some aspects.

[0009] Figure 1B and Figure 1C The non-roaming 5G system architecture is shown based on some aspects.

[0010] Figure 2 , Figure 3 and Figure 4 Various systems, devices, and components capable of implementing various aspects of the disclosed embodiments are shown.

[0011] Figure 5 The protocol layering for reliable data service (RDS) delivery between a UE and the Service Capability Exposure Function (SCEF) in an evolved packet system (EPS) is illustrated according to some embodiments.

[0012] Figure 6 The protocol layering for RDS delivery between a UE and a Network Exposure Function (NEF) in a 5G system (5GS) is illustrated according to some embodiments.

[0013] Figure 7 The format of the Manage_Port command field for the action "Query Port" is shown according to some embodiments.

[0014] Figure 8 The format of the Manage_Port response field for the action "Query Port" is shown according to some embodiments.

[0015] Figure 9 The format of the Manage_Port command field for the action "notification port" is shown according to some embodiments.

[0016] Figure 10 Block diagrams are shown of communication devices such as evolved Node B (eNB), next-generation Node B (gNB) (or another RAN node), access point (AP), radio station (STA), mobile station (MS), or user equipment (UE) based on various aspects. Detailed Implementation

[0017] The following description and accompanying drawings fully illustrate the various aspects to enable those skilled in the art to implement them. Other aspects may include structural, logical, electrical, procedural, and other variations. Parts and features of some aspects may be included in, or substitute for, parts and features of other aspects. The aspects set forth in the claims include all available equivalents of these claims.

[0018] Figure 1A The architecture of a network is illustrated according to several aspects. Network 140A is shown as including User Equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless phone, drone, or any other computing device including wired and / or wireless communication interfaces. UE 101 and 102 may be collectively referred to herein as UE 101, and UE 101 may be used to perform one or more of the techniques disclosed herein.

[0019] Any radio link described herein (e.g., as used in Network 140A or any other illustrated network) may operate according to any exemplary radio communication technology and / or standard.

[0020] LTE and LTE Advanced are standards for high-speed data wireless communication for UEs such as mobile phones. In LTE Advanced and various wireless systems, carrier aggregation is a technique that allows the use of multiple carrier signals operating at different frequencies to carry the communication of a single UE, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation can be used when one or more component carriers are operating on unlicensed frequencies.

[0021] The aspects described herein can be used in the context of any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., Licensed Shared Access (LSA) in 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz and other frequencies, and Spectrum Access System (SAS) in 3.55–3.7 GHz and other frequencies).

[0022] The aspects described herein can also be applied to different single-carrier or OFDM types (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.) by assigning OFDM carrier data bit vectors to corresponding symbol resources (especially 3GPP NR (New Radio)).

[0023] In some aspects, either UE 101 or 102 may include an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connectivity. In some aspects, either UE 101 or 102 may include a Narrowband (NB) IoT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a Public Land Mobile Network (PLMN), Proximity-Based Service (ProSe) or Device-to-Device (D2D) communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated. The IoT network includes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connectivity. The IoT UE may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0024] In some respects, either UE 101 or 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0025] UEs 101 and 102 can be configured to connect (e.g., communicatively coupled) to a radio access network (RAN) 110. RAN 110 can be, for example, Universal Mobile Telecommunications System (UMTS), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Next Generation RAN (NG RAN), or other types of RAN. UEs 101 and 102 utilize connections 103 and 104, respectively, each connection including a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces enabling communicative coupling and can conform to cellular communication protocols such as Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA) network protocols, Push-to-Talk (PTT) protocols, PTT on Cellular (POC) protocols, Universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, 5G protocols, New Radio (NR) protocols, etc.

[0026] In one aspect, UEs 101 and 102 can further exchange communication data directly through the ProSe interface 105. The ProSe interface 105 may also be referred to as a sidelink interface, which includes one or more logical channels, including but not limited to the Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Discovery Channel (PSDCH), and Physical Sidelink Broadcast Channel (PSBCH).

[0027] UE 102 is shown configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may include Wi-Fi. Router. In this example, AP 106 is shown as a core network connected to the Internet but not to the wireless system (described in further detail below).

[0028] RAN 110 may include one or more access nodes that enable connections to 103 and 104. These access nodes (ANs) may be referred to as base stations (BS), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN network nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). In the case that communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) for providing macro cells, and one or more RAN nodes (e.g., low-power (LP) RAN node 112, or auxiliary RAN node 112 based on unlicensed spectrum) for providing femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro cells).

[0029] Either RAN node 111 or 112 can terminate the air interface protocol and can be the first contact point for UEs 101 and 102. In some aspects, either RAN node 111 or 112 can implement various logical functions of RAN 110, including but not limited to Radio Network Controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and packet scheduling, and mobility management. In one example, either node 111 or 112 can be a Next Generation Node B (gNB), an Evolved Node B (eNB), or other types of RAN node.

[0030] RAN 110 is shown communicatively coupled to core network (CN) 120 via S1 interface 113. In various aspects, CN 120 may be an evolved packet core (EPC) network, a next-generation packet core (NPC) network, or some other type of CN (e.g., see reference 113). Figures 1B to 1C (As shown). In this aspect, the S1 interface 113 is divided into two parts: the S1-U interface 114, which carries user traffic data between RAN nodes 111 and 112 and the serving gateway (S-GW) 122; and the S1 mobility management entity (MME) interface 115, which is the signaling interface between RAN nodes 111 and 112 and the MME 121.

[0031] In this respect, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 can functionally resemble the control plane of a traditional Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 can manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 can include a database of network users, including subscription-related information used to support network entities in handling communication sessions. CN 120 can include one or more HSS 124s, depending on the number of mobile subscribers, equipment capacity, network organization, etc. For example, HSS 124 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc.

[0032] The S-GW 122 can terminate the S1 interface 113 toward RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 can serve as a local mobility anchor for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0033] P-GW 123 can terminate an SGi interface toward the PDN. P-GW 123 can route data packets between EPC network 120 and external networks (e.g., networks including application server 184 (or application function (AF))) via Internet Protocol (IP) interface 125. P-GW 123 can also transmit data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, application server 184 can be an element that provides IP bearer resources for use with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.). In this aspect, P-GW 123 is shown communicatively coupled to application server 184 via IP interface 125. Application server 184 can also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via CN 120.

[0034] P-GW 123 can also be a node for policy enforcement and charging data collection. The Policy and Charging Rule Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, a single PCRF may exist in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In roaming scenarios with local traffic disruptions, two PCRFs may exist associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) within the HPLMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to application server 184 via P-GW 123.

[0035] In some aspects, the communication network 140A can be an IoT network or a 5G network, including new 5G radio networks using licensed (5G NR) and unlicensed (5G NR-U) spectrum for communication. Currently, one implementation of IoT is narrowband IoT (NB-IoT).

[0036] The NG system architecture may include a RAN 110 and a 5G network core (5GC) 120. The NG-RAN 110 may include multiple nodes, such as gNBs and NG-eNBs. The core network 120 (e.g., a 5G core network or 5GC) may include Access and Mobility Functions (AMF) and / or User Plane Functions (UPF). The AMF and UPF can be communicatively coupled to the gNB and NG-eNB via NG interfaces. More specifically, in some aspects, the gNB and NG-eNB can connect to the AMF via an NG-C interface and to the UPF via an NG-U interface. The gNB and NG-eNB can be coupled to each other via an Xn interface.

[0037] In some aspects, the NG system architecture can use reference points among various nodes, as provided by 3GPP Technical Specification (TS) 23.501 (e.g., V15.4.0, 2018-12). In some aspects, each gNB and NG-eNB can be implemented as a base station, mobile edge server, small cell, home eNB, RAN network node, etc. In some aspects, in the 5G architecture, the gNB can be the master node (MN), and the NG-eNB can be the slave node (SN). In some aspects, the master / primary node can operate on licensed frequency bands, and the slave node can operate on unlicensed frequency bands.

[0038] Figure 1B This illustrates a non-roaming 5G system architecture based on several aspects. (Reference) Figure 1BThe diagram illustrates a 5G system architecture 140B represented by a reference point. More specifically, UE 102 can communicate with RAN 110 and one or more other 5G core (5GC) network entities. The 5G system architecture 140B includes multiple network functions (NFs), such as Access and Mobility Management Function (AMF) 132, Session Management Function (SMF) 136, Policy Control Function (PCF) 148, Application Function (AF) 150, User Plane Function (UPF) 134, Network Slice Selection Function (NSSF) 142, Authentication Server Function (AUSF) 144, and Unified Data Management (UDM) / Home Subscriber Server (HSS) 146. UPF 134 can provide connectivity to Data Network (DN) 152, which may include, for example, operator services, internet access, or third-party services. AMF 132 can be used to manage access control and mobility, and may also include network slice selection functionality. SMF 136 can be configured to set up and manage various sessions according to network policies. UPF 134 can be deployed in one or more configurations based on the desired service type. PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0039] In some aspects, the 5G system architecture 140B includes an IP Multimedia Subsystem (IMS) 168B and multiple IP Multimedia Core Network Subsystem entities, such as the Call Session Control Function (CSCF). More specifically, the IMS 168B includes a CSCF, which can function as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, and an emergency CSCF (E-CSCF) (in... Figure 1B (Not shown in the image), or query the CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured as the first contact point for UE 102 within the IM subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166B can be configured to act as the contact point for all IMS connections within the operator's network, where the destination of these IMS connections is a subscriber of that network operator or a roaming user currently within that network operator's service area. In some aspects, the I-CSCF 166B can connect to another IP multimedia network 170E, for example, an IMS operated by a different network operator.

[0040] In some respects, the UDM / HSS 146 can be coupled to an application server 160E, which may include a Telephone Application Server (TAS) or other application servers (AS). The AS 160B can be coupled to the IMS 168B via an S-CSCF 164B or an I-CSCF 166B.

[0041] Reference points indicate that interactions can exist between corresponding NF services. For example, Figure 1B The following reference points are shown: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between the two UPF 134, not shown), N10 (between UDM 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AMF 144 and AMF 132). N13 (between AMF 132, not shown), N14 (between the two AMF 132, not shown), N15 (between PCF 148 and AMF 132 in non-roaming scenarios, or between PCF 148 and the visited network and AMF 132 in roaming scenarios, not shown), N16 (between the two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Also available are... Figure 1B Other reference points not shown in the text are indicated.

[0042] Figure 1C The 5G system architecture 140C and its service-based representation are shown. In addition... Figure 1B In addition to the network entities shown, system architecture 140C may also include network exposure function (NEF) 154 and network repository function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and the interaction between network functions may be represented by corresponding point-to-point reference points Ni, or represented as service-based interfaces.

[0043] In some aspects, such as Figure 1CAs shown, service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf 158H (service-based interface presented by AMF 132), Nsmf158I (service-based interface presented by SMF 136), Nnef 158B (service-based interface presented by NEF 154), Npcf158D (service-based interface presented by PCF 148), Nudm 158E (service-based interface presented by UDM 146), Naf158F (service-based interface presented by AF 150), Nnrf 158C (service-based interface presented by NRF 156), Nnssf158A (service-based interface presented by NSSF 142), and Nausf 158G (service-based interface presented by AUSF 144). It is also possible to use... Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0044] Figure 2 , Figure 3 and Figure 4 Various systems, devices, and components capable of implementing various aspects of the disclosed embodiments are illustrated. More specifically, in conjunction with Figures 1A-4 The UE and / or base station (e.g., gNB) discussed may be configured to perform the disclosed techniques.

[0045] Figure 2 The illustration depicts a network 200 according to various embodiments. Network 200 can operate in accordance with 3GPP technical specifications for LTE or 5G / NR systems. However, the exemplary embodiments are not limited in this respect, and the described embodiments can be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, etc.

[0046] Network 200 may include UE 202, which may include any mobile or non-mobile computing device designed to communicate with RAN 204 via an over-the-air connection. UE 202 may be, but is not limited to, smartphones, tablets, wearable computing devices, desktop computers, laptops, in-vehicle infotainment devices, in-vehicle entertainment devices, instrument clusters, head-up displays, in-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networked devices, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0047] In some embodiments, network 200 may include multiple UEs that are directly coupled to each other via sidelink interfaces. The UEs may be M2M / D2D devices that communicate using physical sidelink channels (e.g., but not limited to PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.).

[0048] In some embodiments, UE 202 can also communicate with AP 206 via an over-the-air connection. AP 206 can manage a WLAN connection, which can be used to offload some / all network traffic from RAN 204. The connection between UE 202 and AP 206 can conform to any IEEE 802.11 protocol, wherein AP 206 can be Wireless Fibre Channel. Router. In some embodiments, UE 202, RAN 204, and AP 206 may utilize cellular WLAN aggregation (e.g., LWA / LWIP). Cellular WLAN aggregation may involve RAN 204 configuring UE 202 to utilize both cellular radio resources and WLAN resources.

[0049] RAN 204 may include one or more access nodes, such as Access Node (AN) 208. AN 208 can terminate the air interface protocol of UE 202 by providing access layer protocols including RRC, Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), MAC, and L1 protocols. In this way, AN 208 can achieve data / voice connectivity between the core network (CN) 220 and UE 202. In some embodiments, AN 208 may be implemented in a discrete device or as one or more software entities running on a server computer as part of a virtual network, such as a CRAN or virtual baseband unit pool. AN 208 is referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. AN 208 may be a macrocell base station or a low-power base station used to provide femtocells, picocells, or other similar cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0050] In embodiments where RAN 204 includes multiple ANs, they can be coupled to each other via an X2 interface (in the case of RAN 204 being an LTE RAN) or an Xn interface (in the case of RAN 204 being a 5G RAN). In some embodiments, the X2 / Xn interfaces, which can be separated into control / user plane interfaces, can allow ANs to transmit and handle information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0051] Each AN of RAN 204 can manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to UE 202. UE 202 can simultaneously connect to multiple cells provided by the same or different ANs of RAN 204. For example, UE 202 and RAN 204 can use carrier aggregation to allow UE 202 to connect to multiple component carriers, each component carrier corresponding to a Pcell or Scell. In a dual connectivity scenario, the first AN can be the primary node providing the MCG, and the second AN can be the secondary node providing the SCG. The first / second AN can be any combination of eNB, gNB, ng-eNB, etc.

[0052] RAN 204 can provide an air interface on either licensed or unlicensed spectrum. For operation in unlicensed spectrum, nodes can use LAA, eLAA, and / or feLAA mechanisms based on CA technology with PCell / Scell. Before accessing unlicensed spectrum, nodes can perform medium / carrier sensing operations based on, for example, a Listen-Before-Speak (LBT) protocol.

[0053] In a V2X scenario, UE 202 or AN 208 can be or act as a Roadside Unit (RSU), which can refer to any transport infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE is referred to as a "UE-type RSU"; an RSU implemented in or by an eNB is referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB is referred to as a "gNB-type RSU"; and so on. In one example, an RSU is a computing device coupled to roadside radio frequency circuitry (which provides connectivity support for passing vehicle UEs). An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. An RSU can provide very low-latency communication required for high-speed events such as collision avoidance, traffic warnings, etc. Additionally or alternatively, an RSU can provide other cellular / WLAN communication services. RSU components can be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic signal controllers or backhaul networks.

[0054] In some embodiments, RAN 204 may be LTE RAN 210, which includes an eNB (e.g., eNB 212). LTE RAN 210 can provide an LTE air interface with the following characteristics: a 15 kHz subcarrier spacing (SCS); CP-OFDM waveforms for downlink (DL) and SC-FDMA waveforms for uplink (UL); Turbo codes for data and TBCC for control; and so on. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; rely on PDSCH / PDCCHDMRS for PDSCH / PDCCH demodulation; and rely on CRS for cell search and initial acquisition, channel quality measurement, and channel estimation for coherent demodulation / detection at the UE. The LTE air interface can operate in the sub-6 GHz band.

[0055] In some embodiments, RAN 204 may be NG-RAN 214, which includes a gNB (e.g., gNB 216) or an ng-eNB (e.g., ng-eNB 218). gNB 216 can connect to a 5G-enabled UE using a 5G NR interface. gNB 216 can connect to the 5G core via an NG interface, which may include an N2 interface or an N3 interface. ng-eNB 218 can also connect to the 5G core via an NG interface, but can connect to the UE via an LTE air interface. gNB 216 and ng-eNB 218 can connect via an Xn interface.

[0056] In some embodiments, the NG interface can be divided into two parts: the NG user plane (NG-U) interface and the NG control plane (NG-C) interface. The former (e.g., the N3 interface) carries traffic data between the nodes of NG-RAN 214 and UPF 248, while the latter is the signaling interface (e.g., the N2 interface) between the nodes of NG-RAN 214 and AMF 244.

[0057] NG-RAN 214 can provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polarity, repetition, simplex and Reed-Muller codes for control, and LDPC for data. The 5G-NR air interface can rely on CSI-RS, PDSCH / PDCCH DMRS similar to those of the LTE air interface. The 5G-NR air interface can operate without CRS, but can use PBCH DMRS for PBCH demodulation; PTRS for PDSCH phase tracking; and a tracking reference signal for time tracking. The 5G-NR air interface can operate on the FR1 band, including the sub-6GHz band, or the FR2 band, including the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include a synchronization signal and physical broadcast channel (SS / PBCH) block (SSB), which is an area of ​​the downlink resource grid that includes the PSS / SSS / PBCH.

[0058] In some embodiments, the 5G-NR air interface can use the Bandwidth Part (BWP) for various purposes. For example, the BWP can be used for dynamic adaptation of the SCS. For instance, UE 202 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to UE 202, the transmitted SCS also changes. Another example of a BWP use case relates to power saving. Specifically, multiple BWPs with different numbers of frequency resources (e.g., PRBs) can be configured for UE 202 to support data transmission under different traffic load scenarios. A BWP containing fewer PRBs can be used for data transmission with lower traffic loads, while allowing power saving at UE 202 and, in some cases, gNB 216. A BWP containing more PRBs can be used for scenarios with higher traffic loads.

[0059] RAN 204 is communicatively coupled to CN 220, which includes network elements, to provide various functions supporting data and telecommunications services to customers / subscribers (e.g., users of UE 202). Components of CN 220 may be implemented in a single physical node or in different physical nodes. In some embodiments, NFV can be used to virtualize any or all of the functions provided by the network elements of CN 220 onto physical computing / storage resources such as servers, switches, etc. A logical instance of CN 220 may be referred to as a network slice, and a logical instance of a portion of CN 220 may be referred to as a network subslice.

[0060] In some embodiments, CN 220 can be connected to an LTE radio network as part of an Enhanced Packet System (EPS) 222, which may also be referred to as an EPC (or Enhanced Packet Core). As shown, EPC 222 may include MME 224, SGW 226, SGSN 228, HSS 230, PGW 232, and PCRF 234 coupled to each other via interfaces (or "reference points"). The functions of the components of EPC 222 are briefly described below.

[0061] MME 224 enables mobility management functions to track the current location of UE 202, facilitating paging, bearer activation / deactivation, handover, gateway selection, authentication, and more. MME 224 can be coupled to Service Capability Exposure (SCEF) 227 via the T6a interface.

[0062] SGW 226 can terminate S1 interfaces destined for the RAN and route data packets between the RAN and EPC 222. SGW 226 can serve as a local mobility anchor for handover between RAN nodes and can also provide anchoring for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

[0063] SGSN 228 can track the location of UE 202 and perform security functions and access control. Furthermore, SGSN 228 can perform EPC inter-node signaling for mobility between different RAT networks; perform PDN and S-GW selection as specified by MME 224; perform MME selection for handover; and so on. The S3 reference point between MME 224 and SGSN 228 enables the exchange of user and bearer information for 3GPP indirect network access mobility in idle / active states.

[0064] HSS 230 may include a database for network users, containing subscription-related information to support network entities in processing communication sessions. HSS 230 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, etc. The S6a reference point between HSS 230 and MME 224 enables the transmission of subscription and authentication data for authenticating / authorizing user access to LTE CN 220.

[0065] PGW 232 can terminate the SGi interface to a data network (DN) 236, which may include an application / content server 238. PGW 232 can route data packets between the LTE CN 220 and the data network 236. PGW 232 can be coupled to SGW 226 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 232 may also include nodes for policy enforcement and charging data collection (e.g., PCEF). Furthermore, the SGi reference point between PGW 232 and the data network 236 can be, for example, an external public or private PDN or an internal packet data network used for configuring IMS services. PGW 232 can be coupled to PCRF 234 via a Gx reference point.

[0066] PCRF 234 is the policy and charging control element of LTE CN 220. PCRF 234 can be communicatively coupled to application / content server 238 to determine appropriate QoS and charging parameters for service flows. PCRF 234 can configure associated rules (via Gx reference point) to PCEF with appropriate TFT and QCI.

[0067] In some embodiments, CN 220 may be 5GC 240. As shown, 5GC 240 may include AUSF 242, AMF 244, SMF 246, UPF 248, NSSF 250, NEF 252, NRF254, PCF 256, UDM 258, and AF 260 coupled to each other via interfaces (or "reference points"). The functions of the components of 5GC 240 can be briefly described below.

[0068] The AUSF 242 can store data for UE 202 authentication and handle authentication-related functions. The AUSF 242 facilitates a common authentication framework for various access types. In addition to communicating with other components of the 5GC 240 via a reference point, as shown in the figure, the AUSF 242 can also demonstrate an interface based on Nausf services.

[0069] AMF 244 allows other functions of 5GC 240 to communicate with UE 202 and RAN 204 and subscribe to notifications about mobility events for UE 202. AMF 244 can handle registration management (e.g., for registering UE 202), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 244 can provide the transmission of SM messages between UE 202 and SMF 246 and acts as a transparent broker for routing SM messages. AMF 244 can also provide the transmission of SMS messages between UE 202 and SMSF 246. AMF 244 can interact with AMF 242 and UE 202 to perform various security anchoring and context management functions. Furthermore, AMF 244 can be the termination point of the RAN CP interface, which may include or be the N2 reference point between RAN 204 and AMF 244; and AMF 244 can serve as the termination point for NAS (N1) signaling, performing NAS encryption and integrity protection. AMF 244 can also support NAS signaling with UE 202 via the N3 IWF interface.

[0070] SMF 246 can be responsible for: SM (e.g., session establishment, tunnel management between UPF 248 and AN 208); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring traffic manipulation at UPF 248 to route traffic to the correct destination; terminating interfaces to policy control functions; controlling policy enforcement, charging, and QoS as a part; lawful interception (for SM events and interfaces to the LI system); terminating the SM portion of NAS messages; downlink data notification; initiating AN-specific SM messages, which are sent to AN 208 via N2 through AMF 244; and determining the SSC mode of the session. SM can refer to the management of PDU sessions, and a PDU session or "session" can refer to the PDU connectivity service that provides or enables PDU exchange between UE 202 and data network 236.

[0071] UPF 248 can act as an anchor point for mobility within and between RATs, an external PDU session point interconnecting with data network 236, and a branch point supporting multi-homed PDU sessions. UPF 248 can also perform packet routing and forwarding, perform packet inspection, enforce the user plane portion of policy rules, enforce legitimate packet interception (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic authentication (e.g., SDF to QoS flow mapping), perform transport-level packet marking in uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 248 may include an uplink classifier to support traffic flow routing to the data network.

[0072] NSSF 250 can select a set of network slice instances to serve UE 202. If needed, NSSF 250 can also determine the allowed NSSAIs and the mapping to subscribed S-NSSAIs. NSSF 250 can also determine the set of AMFs to use to serve UE 202 based on appropriate configuration and possibly by querying NRF 254, or determine a list of candidate AMFs. The selection of a set of network slice instances for UE 202 can be triggered by AMF 244 (to which UE 202 registers by interacting with NSSF 250), which may result in changes to the AMFs. NSSF 250 can interact with AMF 244 via reference point N22; and can communicate with another NSSF in the visited network via reference point N31 (not shown). Furthermore, NSSF 250 can expose an interface based on NNSSF services.

[0073] NEF 252 can securely expose services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, AFs (e.g., AF 260), edge computing, or fog computing systems. In such embodiments, NEF 252 can authenticate, authorize, or suppress AFs. NEF 252 can also translate information exchanged with AF 260 and information exchanged with internal network functions. For example, NEF 252 can translate between AF service identifiers and internal 5GC information. NEF 252 can also receive information from other NFs based on their exposure capabilities. This information can be stored as structured data in NEF 252 or stored in a data storage device NF using a standardized interface. NEF 252 can then re-expose the stored information to other NFs and AFs, or for other purposes such as analytics. Furthermore, NEF 252 can expose interfaces based on Nnef services.

[0074] NRF 254 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to those instances. NRF 254 also maintains information about available NF instances and the services they support. As used herein, terms such as "instantiate" and "instantiation" refer to the creation of an instance, while "instance" refers to the concrete occurrence of an object, for example, an object that can appear during program code execution. Furthermore, NRF 254 can demonstrate interfaces based on NRF services.

[0075] PCF 256 can provide policy rules to control plane functions to enforce these rules, and it also supports a unified policy framework for managing network behavior. PCF 256 can also implement a frontend to access subscription information related to policy decisions in the UDR of UDM 258. In addition to communicating with functions via reference points as shown in the figure, PCF 256 also demonstrates an interface based on Npcf services.

[0076] UDM 258 can process subscription-related information to support network entities in handling communication sessions and can store subscription data for UE 202. For example, subscription data can be transmitted via the N8 reference point between UDM 258 and AMF 244. UDM 258 can include two parts: an application front-end and a UDR. The UDR can store subscription data and policy data for UDM 258 and PCF 256, and / or store structured data and application data (including PFDs for application detection and application request information for multiple UEs 202) for NEF 252 for exposure. UDR 221 can expose a Nudr-based service interface to allow UDM 258, PCF 256, and NEF 252 to access specific sets of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of related data changes in the UDR. UDM can include UDM-FE, responsible for handling credentials, location management, subscription management, etc. Several different front-ends can serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as shown in the figure, the UDM 258 can also demonstrate interfaces based on Nudm services.

[0077] AF 260 can provide application impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

[0078] In some embodiments, 5GC 240 can implement edge computing by selecting an operator / third-party service that is geographically close to the network to which UE 202 is attached. This can reduce latency and load on the network. To provide edge computing implementation, 5GC 240 can select a UPF 248 close to UE 202 and perform traffic manipulation from UPF 248 to data network 236 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 260. In this way, AF 260 can influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 260 is considered a trusted entity, the network operator can permit AF 260 to interact directly with the relevant NF. Furthermore, AF 260 can expose interfaces based on Naf services.

[0079] Data network 236 can represent various network operator services, Internet access, or third-party services that can be provided by one or more servers (including, for example, application / content server 238).

[0080] Figure 3 A wireless network 300 according to various embodiments is schematically illustrated. The wireless network 300 may include a UE 302 that communicates wirelessly with an AN 304. The UE 302 and the AN 304 may be similar to and substantially interchangeable with components of the same name described elsewhere herein.

[0081] UE 302 can be communicatively coupled to AN 304 via connection 306. Connection 306 is shown as an air interface for communication coupling and can comply with cellular communication protocols operating at millimeter wave or sub-6 GHz frequencies, such as LTE or 5G NR protocols.

[0082] UE 302 may include a host platform 308 coupled to modem platform 310. Host platform 308 may include application processing circuitry 312, which may be coupled to protocol processing circuitry 314 of modem platform 310. Application processing circuitry 312 may run various applications for UE 302 to originate / aggregate application data. Application processing circuitry 312 may also implement one or more layers of operation to send / receive application data to / from a data network. These layer operations may include transport (e.g., UDP) and Internet (e.g., IP) operations.

[0083] Protocol processing circuitry 314 can implement one or more layer operations to facilitate the transmission or reception of data via connection 306. Layer operations implemented by protocol processing circuitry 314 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0084] The modem platform 310 may also include digital baseband circuitry 316, which can implement one or more layer operations "below" the layer operations performed by the protocol processing circuitry 314 in the network protocol stack. These operations may include, for example, one or more of the following PHY operations: HARQ-ACK function, scrambling / descrambling, encoding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bit metric determination, and multi-antenna port precoding / decoding. These functions may include one or more of the following: space-time, space-frequency, or spatial coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, blind decoding of control channel signals, and other related functions.

[0085] The modem platform 310 may also include transmitting circuitry 318, receiving circuitry 320, RF circuitry 322, and an RF front-end (RFFE) 324, which may include or be connected to one or more antenna panels 326. In short, transmitting circuitry 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc.; receiving circuitry 320 may include an analog-to-digital converter, a mixer, an IF component, etc.; RF circuitry 322 may include a low-noise amplifier, a power amplifier, a power point tracking component, etc.; and RFFE 324 may include filters (e.g., surface acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of transmitting circuitry 318, receiving circuitry 320, RF circuitry 322, RFFE 324, and antenna panels 326 (collectively, the "transmit / receive components") may be specific to the details of a particular implementation, such as whether the communication is TDM or FDM, or at millimeter-wave or sub-6 GHz frequencies. In some embodiments, the transmitting / receiving components may be arranged in multiple parallel transmitting / receiving chains, or may be arranged in the same or different chips / modules, etc.

[0086] In some embodiments, the protocol processing circuit 314 may include one or more instances of control circuitry (not shown) to provide control functions for the transmitting / receiving components.

[0087] UE reception can be established via and through antenna panel 326, RFFE 324, RF circuit 322, receiving circuit 320, digital baseband circuit 316, and protocol processing circuit 314. In some embodiments, antenna panel 326 can receive transmissions from AN 304 via receive beamforming signals received by a plurality of antennas / antenna elements of one or more antenna panels 326.

[0088] UE transmission can be established via and through protocol processing circuitry 314, digital baseband circuitry 316, transmission circuitry 318, RF circuitry 322, RFFE 324, and antenna panel 326. In some embodiments, the transmission components of UE 302 may apply spatial filters to the data to be transmitted to form a transmission beam emitted by the antenna elements of antenna panel 326.

[0089] Similar to UE 302, AN 304 may include a host platform 328 coupled to a modem platform 330. Host platform 328 may include application processing circuitry 332 coupled to protocol processing circuitry 334 of modem platform 330. The modem platform may also include digital baseband circuitry 336, transmitting circuitry 338, receiving circuitry 340, RF circuitry 342, RFFE circuitry 344, and antenna panel 346. Components of AN 304 may be similar to and substantially interchangeable with their namesake components in UE 302. In addition to performing data transmission / reception as described above, components of AN 304 may perform various logical functions, including, for example, RNC functions (e.g., radio bearer management), uplink and downlink dynamic radio resource management, and data packet scheduling.

[0090] Figure 4 The block diagrams illustrated below are based on some example embodiments of components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and executing any one or more instructions of the methods discussed herein. Specifically, Figure 4 A schematic representation of hardware resources 400 is shown, including one or more processors (or processor cores) 410, one or more memory / storage devices 420, and one or more communication resources 430, each of which can be communicatively coupled via bus 440 or other interface circuitry. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 402 can be executed to provide an execution environment utilizing hardware resources 400 to one or more network slices / subslices.

[0091] Processor 410 may include, for example, processor 412 and processor 414. Processor 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0092] Memory / storage device 420 may include main memory, disk storage devices, or any suitable combination thereof. Memory / storage device 420 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage devices, etc.

[0093] Communication resource 430 may include an interconnect or network interface controller, component, or other suitable device for communicating with one or more peripheral devices 404 or one or more databases 406 or other network elements via network 408. For example, communication resource 430 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth, etc. (or Bluetooth) Low-power components Components, and other communication components.

[0094] Instructions 450 may include software, programs, applications, applets, apps, or other executable code for causing at least any processor 410 to perform any one or more of the methods discussed herein. Instructions 450 may reside wholly or partially within at least one of: processor 410 (e.g., within the processor's cache memory), memory / storage device 420, or any suitable combination thereof. Furthermore, any portion of instructions 450 may be transferred from any combination of peripheral device 404 or database 406 to hardware resource 400. Thus, the memory of processor 410, memory / storage device 420, peripheral device 404, and database 406 are examples of computer-readable and machine-readable media.

[0095] For one or more embodiments, at least one component outlined in one or more prior drawings may be configured to perform one or more operations, techniques, processes, and / or methods as outlined in the Examples section below. For example, baseband circuitry as described above in conjunction with one or more prior drawings may be configured to operate according to one or more examples set forth below. As another example, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more prior drawings may be configured to operate according to one or more examples set forth below in the Examples section.

[0096] The term "application" can refer to a complete and deployable package or environment that implements a certain function in an operating environment. The term "AI / ML application," etc., can refer to an application that includes some artificial intelligence (AI) / machine learning (ML) models and an application-level description. In some embodiments, an AI / ML application can be used to configure or implement one or more of the disclosed aspects.

[0097] The term "machine learning" or "ML" refers to the use of computer systems to implement algorithms and / or statistical models to perform one or more specific tasks without using explicit instructions, but instead relying on patterns and inferences. ML algorithms build or estimate one or more mathematical models (called "ML models," etc.) to make predictions or decisions based on sample data (referred to as "training data," "model training information," etc.) without being explicitly programmed to perform these tasks. Typically, an ML algorithm is a computer program that learns from experience regarding certain tasks and certain performance metrics, and an ML model can be any object or data structure created after training an ML algorithm using one or more training datasets. After training, the ML model can be used to make predictions on new datasets. While the term "ML algorithm" refers to a different concept than the term "ML model," these terms discussed herein are used interchangeably in this disclosure.

[0098] The terms "machine learning model," "ML model," etc., can also refer to the ML methods and concepts used in ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms during operation to solve a specific use case. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithms, support vector machines, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed robber learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model can have many sub-models as components, and the ML model can train all sub-models together. Individually trained ML models can also be chained together in an ML pipeline during inference. An "ML pipeline" is a collection of functional, feature, or functional entities specific to an ML-assisted solution; an ML pipeline can include one or more data sources among a data pipeline, a model training pipeline, a model evaluation pipeline, and actors. An "actor" is an entity that uses the output of the ML model's inference to host the ML-assisted solution. The term "ML training host" refers to the entity that hosts the training of a model, such as a network function. The term "ML inference host" refers to the entity that hosts the model during inference mode (which includes model execution and any applicable online learning). The ML host informs the actors of the output of the ML algorithm, and the actors decide on actions ("actions" are performed by the actors as a result of the ML-assisted solution output). The term "model inference information" refers to the information used as input to the ML model to determine one or more inferences; the data used to train the ML model and the data used to determine the inference may overlap; however, "training data" and "inference data" refer to different concepts.

[0099] Mobile communications have evolved significantly from early voice systems to today's highly complex integrated communication platforms. Next-generation wireless communication systems (5G or New Radio (NR)) will provide ubiquitous information access and data sharing for a wide range of users and applications. NR promises to be a unified network / system designed to meet diverse and sometimes conflicting performance dimensions and services. This diverse, multidimensional demand is driven by different services and applications. Generally, NR will evolve from 3GPP LTE Advanced, adding more potential New Radio Access Technologies (RATs) to enrich people's lives with better, simpler, and seamless wireless connectivity solutions. NR enables wireless communication and delivers fast, rich content and services.

[0100] The Reliable Data Service (RDS) protocol can be used to perform non-IP data transfer between the UE and SCEF / PDN-GW. This protocol is currently used in 4G and is also used in 5G systems for Cellular Internet of Things (CIoT) type applications. In some aspects, commands and responses in the RDS protocol are contained in a single frame and do not require segmentation and reassembly. However, the maximum length of the Manage_Port (or management port) command can be 4098 octets, and support for segmentation and reassembly of commands and responses may need to be added.

[0101] The disclosed technology can be used as a way to extend the RDS protocol to support the segmentation and reassembly of commands and responses.

[0102] In some embodiments, under certain operating systems (OSS), the application identifier may be very long, and the information requested by the Manage_Port command may not meet the 1520 octet limit of the RDS frame in the case of query ports and notification ports.

[0103] One solution to the above problem is to segment the frame. Another approach is to provide information for only a limited number of ports in a single frame, and have the initiator or receiver request information for the remaining ports in a subsequent command.

[0104] In some embodiments, the initiating UE (also referred to as the initiating device or initiator) may explicitly indicate the destination port number for the information it wants to query. The receiving UE (also referred to as the receiving device or receiver) may indicate whether information for all destination ports is included in the response, and if not, indicate the destination port numbers for which the information is not included. The initiator can then query information for these ports in subsequent commands. Frame segmentation may not be provided.

[0105] In some embodiments, for notification ports, as much information as possible that can be included in a single frame is sent to the receiver. The initiator may indicate reserved port numbers whose information is not included. The receiver can use a query port action to query information for these ports.

[0106] Figure 5 A protocol layer 500 is shown, according to some embodiments, for reliable data service (RDS) delivery between a UE and the Service Capability Exposure Function (SCEF) in an evolved packet system (EPS).

[0107] Figure 6 A protocol layer 600 for RDS delivery between a UE and a Network Exposure Function (NEF) in a 5G system (5GS) is shown according to some embodiments.

[0108] General Manage_Port configuration

[0109] Action field (bits 1 to 4, octet 1)

[0110] As part of the MANAGE_PORT command or response, this field indicates the action performed by the initiator or receiver and can have the following values ​​as indicated in Table 1.

[0111]

[0112] Table 1

[0113] Application ID

[0114] This field should be encoded as follows: a 16-byte OS Id field, an 8-byte OS Application Id length field, and an OS Application Id field. The OS Id is the operating system identifier and contains the UUID specified in IETF RFC 4122. The OS Application Id field contains a variable-length 8-byte OS-specific application identifier.

[0115] Status (2 octets)

[0116] This field is used only in response frames from the receiver to the initiator. It specifies the status of the operation and can have the following values ​​provided in Table 2.

[0117]

[0118] Table 2

[0119] Requested port number

[0120] This field indicates the destination port number that the initiator wants to query, and can be encoded as a two-eight-byte bitmap, as indicated in Table 3.

[0121]

[0122]

[0123] Table 3

[0124] Port number unavailable

[0125] This field indicates the port number that is reserved and whose information is not included in the command or response frame. This field should be encoded as a two-octet bitmap similar to the "Requested Port Number" field.

[0126] Query port number

[0127] Figure 7The Manage_Port command field format 700 for the action "Query Port" is shown according to some embodiments.

[0128] In some embodiments, if the initiator wants to query the reserved destination port number, the initiator should send a message such as Figure 7 The MANAGE_PORT command shown is executed by setting the action field to "Query Port" and specifying all destination port numbers to be queried in the "Requested Port Number" field.

[0129] Figure 8 The Manage_Port response field format 800 for the action "Query Port" is shown according to some embodiments.

[0130] In some embodiments, the recipient may send, such as Figure 8 The MANAGE_PORT response shown is executed by setting the Action field in the response frame to "Query Port". For each destination port held by the receiver and associated with the application, included in the "Requested Port Number" field of the MANAGE_PORT command, the receiver should include one entry in the MANAGE_PORT response. In some embodiments, the receiver may set the Quantity Entries field in the MANAGE_PORT response to the number of destination port entries included in the MANAGE_PORT response. For each destination port entry, the receiver should include the source port number paired with the destination port and the associated application ID. If the receiver has not held any source port number for the associated application ID, the source port number should be set to 0. Entries for all destination port numbers requested by the initiator may not be able to fit in the MANAGE_PORT response. In this case, the receiver should include as many entries as possible regarding destination port numbers in the MANAGE_PORT response. For all destination port numbers held by the receiver, for which the initiator has requested information in the requested port numbers in the MANAGE_PORT command, and whose information cannot be included in the MANAGE_PORT response, the receiver should set the corresponding entry in the Port Number Unavailable Bitmap. The initiator can then query information about these destination port numbers by sending another MANAGE_PORT command and setting the requested port number to a port number that is not available in the received MANAGE_PORT response.

[0131] Notification port number

[0132] Figure 9 The Manage_Port command field format 900 for the action "notification port" is shown according to some embodiments.

[0133] In some embodiments, if the initiator wants to notify the receiver of the source port number held by the initiator, the initiator can send, for example... Figure 9 The MANAGE_PORT command shown is executed by setting the action field to "notification port".

[0134] For each source port that is reserved by the initiator and associated with an application, the initiator may include one entry in the MANAGE_PORT command. In some embodiments, the initiator may set the number of entries field in the MANAGE_PORT command to the number of source port entries included in the MANAGE_PORT response. For each reserved source port, the initiator should include the destination port number paired with the source port and the associated application ID. If the initiator has not reserved any destination port number for the associated application ID, the destination port number may be set to 0.

[0135] In some embodiments, entries for all source port numbers may not be contained in the MANAGE_PORT command. In this case, the initiator may include as many entries as possible for source port numbers in the MANAGE_PORT command. For all source port numbers that the initiator has reserved information for and whose information cannot be included in the MANAGE_PORT command, the initiator may set the corresponding entries in the port number unavailable bitmap. The receiver can then query information about these source port numbers by sending another MANAGE_PORT command with the action field set to "Query Port" and the "Requested Port Number" field set to a port number that is unavailable in the received MANAGE_PORT command.

[0136] In some embodiments, when the receiver receives a MANAGE_PORT command with the action field set to "notification port", the receiver may not send a response frame.

[0137] In some embodiments, a 5G system may include a gNB, AMF, SMF, UPF, NEF, UDM, NSSF, AUSF, AF, AS, and other essential elements described in 3GPP TS 23.501 and 3GPP TS 24.501. In some embodiments, the 5G system includes a UE that performs reliable data transfer between the UE and NEF using the RDS protocol as described in TS 24.250. Communication between the UE and NEF is bidirectional and supports MO / MT data transfer in both roaming and non-roaming scenarios. In some embodiments, communication between the UE and NEF can be performed via 3GPP and non-3GPP access. In some embodiments, a MANAGE_PORT command frame with the action field set to query a port includes support for a requested port number field specifying all destination ports for which the initiator wants to query information.

[0138] In some embodiments, the MANAGE_PORT response frame includes support for port number unavailability. Entries for all destination port numbers requested by the initiator may not be contained in the MANAGE_PORT response. In this case, the receiver should include as many entries as possible regarding destination port numbers in the MANAGE_PORT response. For information held by the receiver that the initiator has requested in the MANAGE_PORT command but whose information cannot be included in all destination port numbers in the MANAGE_PORT response, the receiver may set corresponding entries in the port number unavailability bitmap.

[0139] In some embodiments, the initiator can then query information about the remaining destination port numbers by sending another MANAGE_PORT command and setting the requested port number to a port number that was not available in the previously received MANAGE_PORT response.

[0140] In some embodiments, entries for source port numbers may not be accommodated in a MANAGE_PORT command with the action field set to notify the port. In this case, the initiator should include as many entries as possible for source port numbers in the MANAGE_PORT command. For all source port numbers that the initiator has reserved information for and whose information cannot be included in the MANAGE_PORT command, the initiator should set the corresponding entries in the port number unavailable bitmap. The receiver can then query information about these source port numbers by sending another MANAGE_PORT command with the action field set to "Query Port" and the requested port number set to a port number unavailable in the received MANAGE_PORT command.

[0141] Figure 10A block diagram of a communication device, such as an evolved Node B (eNB), a next-generation Node B (gNB) (or another RAN node), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE), is shown, which implements one or more of the technologies disclosed herein. In an alternative aspect, the communication device 1000 may operate as a standalone device or may be connected (e.g., networked) to other communication devices.

[0142] A circuit (e.g., a processing circuit) is a collection of circuits implemented in a tangible entity of a device 1000 that includes hardware (e.g., simple circuits, gates, logic, etc.). Circuit membership can be flexible over time. A circuit includes members that, when operated, can perform a specified operation individually or in combination. In one example, the hardware of a circuit may be permanently designed to perform a specific operation (e.g., hardwired). In another example, the hardware of a circuit may include dynamically connected physical components (e.g., execution units, transistors, simple circuits, etc.), including machine-readable media that are physically modified (e.g., magnetic modifications, electrical modifications, movable placement of invariant aggregated particles, etc.) to encode instructions for a specific operation.

[0143] When connecting physical components, the underlying electrical properties of the hardware components are altered, for example, from an insulator to a conductor, or vice versa. Instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to perform portions of a specific operation during operation by creating members of a circuit with variable connections. Thus, in one example, a machine-readable medium element is either part of a circuit or another component communicatively coupled to the circuit during device operation. In one example, any physical component can be used in more than one member of more than one circuit. For example, during operation, an execution unit may be used in a first circuit of a first circuit system at one point in time and reused at different times by a second circuit in the first circuit system or by a third circuit in the second circuit system. Additional examples of these components of device 1000 are as follows.

[0144] In some respects, device 1000 may operate as a standalone device or may be connected (e.g., networked) to other devices. In a networked deployment, communication device 1000 may operate as a server communication device, a client communication device, or both in a server-client network environment. In one example, communication device 1000 may act as a peer-to-peer (P2P) (or other distributed) network environment. Communication device 1000 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, web appliance, network router, switch, or bridge, or any communication device capable of executing (sequential or otherwise) instructions specifying the actions to be taken by the communication device. Furthermore, although only a single communication device is illustrated, the term "communication device" should also be understood to include any collection of communication devices that individually or jointly execute a set (or more sets) of instructions to perform any or more of the methods discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.

[0145] Examples as described herein may include logic or components, modules, or mechanisms, or may operate on logic or components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specified operation and configured or arranged in a certain manner. In one example, circuitry may be arranged as a module in a specified manner (e.g., internally or to an external entity, such as other circuitry). In one example, all or part of one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) to operate to perform a specified operation. In one example, software may reside on a communication device-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operation.

[0146] Therefore, the term "module" is understood to encompass tangible entities, whether physically constructed, specially configured (e.g., hardwired), or temporarily (e.g., transient) configured (e.g., programmed), to operate or perform part or all of any of the operations described herein in a specified manner. Consider an example where modules are temporarily configured, where it is not necessary to instantiate each module at any given time. For example, in the case where a module comprises a general-purpose hardware processor configured using software, this general-purpose hardware processor can be configured as various different modules at different times. The software can accordingly configure the hardware processor to constitute a specific module at one time and a different module at a different time.

[0147] The communication device (e.g., UE) 1000 may include a hardware processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 1004, a static memory 1006, and a storage device 1007 (e.g., a hard disk drive, a tape drive, a flash memory device, or other block or storage device), some or all of which may communicate with each other via an interconnect link (e.g., a bus) 1008.

[0148] The communication device 1000 may also include a display device 1010, an alphanumeric input device 1012 (e.g., a keyboard), and a user interface (UI) navigation device 1014 (e.g., a mouse). In one example, the display device 1010, input device 1012, and UI navigation device 1014 may be a touchscreen display. The communication device 1000 may also include a signal generating device 1018 (e.g., a speaker), a network interface device 1020, and one or more sensors 1021, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or another sensor. The communication device 1000 may include an output controller 1028, which may be serially (e.g., a universal serial bus, USB), parallelly, or otherwise wired or wirelessly (e.g., infrared (IR), near field communication (NFC), etc.) connected to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0149] Storage device 1007 may include a communication device-readable medium 1022 on which one or more sets of data structures or instructions 1024 (e.g., software) embodying or being utilized by any one or more technologies or functions described herein. In some aspects, registers of processor 1002, main memory 1004, static memory 1006, and / or storage device 1007 may be or may include (fully or at least partially) a device-readable medium 1022 on which one or more sets of data structures or instructions 1024 are stored, embodying or being utilized by any one or more technologies or functions described herein. In one example, one or any combination of hardware processor 1002, main memory 1004, static memory 1006, or mass storage device 1016 may constitute device-readable medium 1022.

[0150] For the purposes of this document, the term "device-readable medium" is used interchangeably with "computer-readable medium" or "machine-readable medium." While the communication device-readable medium 1022 is illustrated as a single medium, the term "communication device-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 1024. The term "communication device-readable medium" encompasses the terms "machine-readable medium" or "computer-readable medium" and can include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 1024) that are executed by the communication device 1000 and cause the communication device 1000 to perform any one or more technologies of this disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of communication device-readable media may include solid-state memory, as well as optical and magnetic media. Specific examples of communication device readable media may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM)), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, the communication device readable medium may include non-transitory communication device readable medium. In some examples, the communication device readable medium may include communication device readable medium that is not a transient propagating signal.

[0151] Commands 1024 can also be sent or received via the communication network 1026 using any of several transmission protocols via the network interface device 1020 through the transmission medium. In one example, the network interface device 1020 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communication network 1026. In one example, the network interface device 1020 may include multiple antennas to communicate wirelessly using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) technologies. In some examples, the network interface device 1020 may utilize multi-user MIMO technology for wireless communication.

[0152] The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the communication device 1000, and includes digital or analog communication signals or other intangible media facilitating the communication of such software. In this context, the transmission medium is a device-readable medium.

[0153] Example

[0154] The following is related to the disclosed technology and Figures 1A-10 Some related additional examples.

[0155] Example 1 is an apparatus for a user equipment (UE) configured to operate in a cellular Internet of Things (CIOT) system, the apparatus comprising: processing circuitry configured to configure the UE as an initiating UE in the CIOT system for Reliable Data Service (RDS) communication, the processing circuitry being configured to: encode a Manage_Port command for transmission to a receiving UE, the Manage_Port command including a query for the availability of a plurality of destination ports of the receiving UE; and decode a Manage_Port response from the receiving UE, the Manage_Port response... Each destination port in the subset of the plurality of destination ports includes: a destination port number of the destination port; a source port number of the source port of the initiating UE paired with the destination port; an application ID of an application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; data encoded in association with the application for RDS communication between the source port identified by the source port number and the destination port of the receiving UE identified by the destination port number; and a memory coupled to the processing circuitry and configured to store the Manage_Port response.

[0156] In Example 2, the subject of Example 1 includes the following subject, wherein the Manage_Port command includes a "Requested Port Number" field that lists the plurality of destination ports of the receiving UE.

[0157] In Example 3, the subject of Examples 1-2 includes the following subject, wherein the Manage_Port response includes a “Quantity Entry” field, which has the number of destination ports included in a subset of the plurality of destination ports in the Manage_Port response.

[0158] In Example 4, the subject matter of Examples 1-3 includes the following subject matter, wherein the processing circuitry is configured to: decode a Manage_Port response from the receiving UE, the Manage_Port response including a "Port Number Unavailable" bitmap, the "Port Number Unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response.

[0159] In Example 5, the subject of Example 4 includes the following subject, wherein the processing circuitry is configured to: encode a second Manage_Port command for transmission to the receiving UE, the second Manage_Port command including a "requested port number" field that lists a remaining subset of the plurality of destination ports.

[0160] In Example 6, the topics of Examples 1-5 include the following, wherein the Manage_Port command further includes an "Action" field that indicates a "Query Port" action associated with a query for the availability of the plurality of destination ports of the receiving UE.

[0161] In Example 7, the topics of Examples 1-6 include the following, wherein the processing circuitry is configured to encode a second Manage_Port command for transmission to the receiving UE, the second Manage_Port command including notification of a plurality of source ports available at the initiating UE.

[0162] In Example 8, the subject of Example 7 includes the following subject, wherein the second Manage_Port command includes a “Quantity Entry” field, which has the number of source ports included in a subset of the plurality of source ports in the Manage_Port response.

[0163] In Example 9, the subject of Example 8 includes the following subject, wherein the second Manage_Port command includes a "Port Number Unavailable" bitmap, which indicates the remaining subset of the plurality of source ports not included in the second Manage_Port command.

[0164] In Example 10, the subject of Example 9 includes the following subject, wherein the processing circuitry is configured to decode a second Manage_Port response from the receiving UE, the second Manage_Port response including a "Requested Port Number" field that lists a remaining subset of the plurality of source ports.

[0165] In Example 11, the subject matter of Examples 1-10 includes: a transceiver circuit coupled to the processing circuit; and one or more antennas coupled to the transceiver circuit.

[0166] Example 12 is a computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE) for configuring the UE as an initiating UE in a cellular Internet of Things (CIOT) system for reliable data service (RDS) communication and causing the UE to perform operations including: encoding a Manage_Port command for transmission to a receiving UE, the Manage_Port command including a query for the availability of a plurality of destination ports of the receiving UE; decoding a Manage_Port response from the receiving UE, the Manage_Port response for each destination port in a subset of the plurality of destination ports including: a destination port number of the destination port; a source port number of the source port of the initiating UE paired with the destination port; and an application ID of an application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; and encoding data associated with the application for RDS communication between the source port identified by the source port number and the destination port of the receiving UE identified by the destination port number.

[0167] In Example 13, the subject of Example 12 includes the following subject, wherein the Manage_Port command includes a "Requested Port Number" field that lists the plurality of destination ports of the receiving UE.

[0168] In Example 14, the topics of Examples 12-13 include the following topic, wherein the Manage_Port response includes a “Quantity Entry” field, which has the number of destination ports included in a subset of the plurality of destination ports in the Manage_Port response.

[0169] In Example 15, the subject of Examples 12-14 includes the operation further comprising: decoding a Manage_Port response from the receiving UE, the Manage_Port response including a "Port Number Unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response.

[0170] In Example 16, the subject of Example 15 includes the operation further comprising: encoding a second Manage_Port command for transmission to the receiving UE, the second Manage_Port command including a "requested port number" field that lists a remaining subset of the plurality of destination ports.

[0171] In Example 17, the topics of Examples 12-16 are as follows, wherein the Manage_Port command further includes an "Action" field that indicates a "Query Port" action associated with a query for the availability of the plurality of destination ports of the receiving UE.

[0172] In Example 18, the subject matter of Examples 12-17 includes the operation further comprising: encoding a second Manage_Port command for transmission to the receiving UE, the second Manage_Port command including notification of a plurality of source ports available at the initiating UE, wherein the second Manage_Port command includes a “quantity entry” field having a number of source ports included in a subset of the plurality of source ports in the Manage_Port response.

[0173] Example 19 is a computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE) for configuring the UE as a receiving UE in a cellular Internet of Things (CIOT) system for reliable data service (RDS) communication and causing the UE to perform operations including: decoding a Manage_Port command received from an initiating UE, the Manage_Port command including a query for the availability of a plurality of destination ports of the receiving UE; encoding a Manage_Port response for transmission to the initiating UE, the Manage_Port response including, for each destination port in a subset of the plurality of destination ports: a destination port number of the destination port; a source port number of a source port of the initiating UE paired with the destination port; and an application ID of an application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; and decoding data received from the initiating UE using RDS communication between the source port identified by the source port number and the destination port of the receiving UE identified by the destination port number, the data being associated with the application.

[0174] In Example 20, the subject of Example 19 includes the operation further comprising: encoding the Manage_Port response to include a "Port Number Unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response; and decoding a second Manage_Port command from the initiating UE, the second Manage_Port command including a "Requested Port Number" field listing a remaining subset of the plurality of destination ports.

[0175] Example 21 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.

[0176] Example 22 is an apparatus that includes means for implementing any of Examples 1-20.

[0177] Example 23 is a system for implementing any of Examples 1-20.

[0178] Example 24 is a method for implementing any of Examples 1-20.

[0179] While one aspect has been described with reference to specific exemplary aspects, it will be apparent that various modifications and changes can be made to these aspects without departing from the broad scope of this disclosure. Accordingly, the specification and drawings are to be considered illustrative rather than restrictive. Therefore, specific embodiments should not be construed as limiting, and the scope of each aspect is defined only by the appended claims together with the full scope of their equivalents.

Claims

1. An apparatus for a user equipment (UE) configured to operate in a cellular Internet of Things (CIOT) system, the apparatus comprising: Processing circuitry, wherein the processing circuitry is configured to configure the UE as an initiating UE in the CIOT system for Reliable Data Service (RDS) communication, the processing circuitry being configured to: The Manage_Port command is encoded for transmission to the receiving UE, the Manage_Port command including a query for the availability of multiple destination ports of the receiving UE; Decode the Manage_Port response from the receiving UE, the Manage_Port response for each destination port in a subset of the plurality of destination ports including: The destination port number of the destination port; The source port number of the source port of the initiating UE paired with the destination port; and The application ID of the application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; and Encode data associated with the application for RDS communication between the source port identified by the source port number and the destination port identified by the destination port number of the receiving UE; and A memory, coupled to the processing circuitry and configured to store the Manage_Port response, The processing circuit is configured to decode a Manage_Port response from the receiving UE, the Manage_Port response including a "Port Number Unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response.

2. The apparatus according to claim 1, wherein, The Manage_Port command includes a "Requested Port Number" field, which lists the plurality of destination ports of the receiving UE.

3. The apparatus according to claim 1, wherein, The Manage_Port response includes a "Quantity Entry" field, which has the number of destination ports included in a subset of the plurality of destination ports in the Manage_Port response.

4. The apparatus according to claim 1, wherein, The processing circuit is configured as follows: A second Manage_Port command is encoded for transmission to the receiving UE, the second Manage_Port command including a "requested port number" field that lists a remaining subset of the plurality of destination ports.

5. The apparatus according to claim 1, wherein, The Manage_Port command also includes an "Action" field that indicates a "Query Port" action associated with a query for the availability of the plurality of destination ports of the receiving UE.

6. The apparatus according to claim 1, wherein, The processing circuit is configured as follows: A second Manage_Port command is encoded for transmission to the receiving UE, the second Manage_Port command including notification of a plurality of source ports available at the initiating UE.

7. The apparatus according to claim 6, wherein, The second Manage_Port command includes a "Quantity Entry" field, which has the number of source ports included in a subset of the plurality of source ports in the Manage_Port response.

8. The apparatus according to claim 7, wherein, The second Manage_Port command includes a "Port Number Unavailable" bitmap, which indicates the remaining subset of the plurality of source ports that are not included in the second Manage_Port command.

9. The apparatus according to claim 8, wherein, The processing circuit is configured as follows: Decode the second Manage_Port response from the receiving UE, the second Manage_Port response including a "Requested Port Number" field that lists the remaining subset of the plurality of source ports.

10. The apparatus according to claim 1, further comprising: The transceiver circuit is coupled to the processing circuit. And one or more antennas are coupled to the transceiver circuit.

11. A computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE), the instructions being configured to configure the UE as an initiating UE in a cellular Internet of Things (CIOT) system for reliable data service (RDS) communication, and to cause the UE to perform operations, the operations including: The Manage_Port command is encoded for transmission to the receiving UE, the Manage_Port command including a query for the availability of multiple destination ports of the receiving UE; Decode the Manage_Port response from the receiving UE, the Manage_Port response for each destination port in a subset of the plurality of destination ports including: The destination port number of the destination port; The source port number of the source port of the initiating UE paired with the destination port; and The application ID of the application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; and Data associated with the application is encoded for RDS communication between the source port identified by the source port number and the destination port identified by the destination port number of the receiving UE. The operation further includes: decoding a Manage_Port response from the receiving UE, the Manage_Port response including a "Port Number Unavailable" bitmap, the "Port Number Unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response.

12. The computer-readable storage medium according to claim 11, wherein, The Manage_Port command includes a "Requested Port Number" field, which lists the plurality of destination ports of the receiving UE.

13. The computer-readable storage medium according to claim 11, wherein, The Manage_Port response includes a "Quantity Entry" field, which has the number of destination ports included in a subset of the plurality of destination ports in the Manage_Port response.

14. The computer-readable storage medium of claim 11, further comprising: A second Manage_Port command is encoded for transmission to the receiving UE, the second Manage_Port command including a "requested port number" field that lists a remaining subset of the plurality of destination ports.

15. The computer-readable storage medium according to claim 11, wherein, The Manage_Port command also includes an "Action" field that indicates a "Query Port" action associated with a query for the availability of the plurality of destination ports of the receiving UE.

16. The computer-readable storage medium of claim 11, further comprising: A second Manage_Port command is encoded for transmission to the receiving UE, the second Manage_Port command including notification of a plurality of source ports available at the initiating UE. The second Manage_Port command includes a "Quantity Entries" field, which has the number of source ports included in a subset of the plurality of source ports in the Manage_Port response.

17. A computer-readable storage medium storing instructions executable by one or more processors of a user equipment (UE), the instructions being configured to configure the UE as a receiving UE in a cellular Internet of Things (CIOT) system for reliable data service (RDS) communication, and to cause the UE to perform operations, the operations including: Decode the Manage_Port command received from the initiating UE, the Manage_Port command including a query for the availability of multiple destination ports of the receiving UE; Encode a Manage_Port response for transmission to the initiating UE, the Manage_Port response including, for each destination port in a subset of the plurality of destination ports: The destination port number of the destination port; The source port number of the source port of the initiating UE paired with the destination port; and The application ID of the application executed on the initiating UE, the application ID corresponding to the destination port number and the source port number; and Decoding involves using RDS communication between the source port (identified by the source port number) and the destination port (identified by the destination port number) of the receiving UE to receive data received from the initiating UE, the data being associated with the application. The operation further includes encoding the Manage_Port response to include a "port number unavailable" bitmap, the "port number unavailable" bitmap indicating a remaining subset of the plurality of destination ports not included in the Manage_Port response.

18. The computer-readable storage medium of claim 17, further comprising: Decode the second Manage_Port command from the initiating UE, the second Manage_Port command including a "Requested Port Number" field, the "Requested Port Number" field listing the remaining subset of the plurality of destination ports.

Images