Method and apparatus for checking port consistency of NIDD messages

Abstract

Embodiments of the present disclosure provide a method and an entity for checking port consistency of NIDD messages. A first aspect of the present disclosure provides a method performed at a first entity (100), including: receiving (S101) a non-Internet protocol data delivery (NIDD) message including one or more RDS port numbers from a second entity; and determining (S102) whether the one or more RDS port numbers are in a configured RDS port list. According to embodiments of the present disclosure, network resources for sending invalid NIDD data can be saved, and undesired actions in a communication system can be avoided.

Description

Technical Field

[0001] The present disclosure generally relates to the technology of communication systems, and more particularly to a method and an entity for checking port consistency of non-Internet Protocol data delivery (NIDD) messages. Background Art

[0002] This section introduces aspects that may help better understand the present disclosure. Therefore, the statements in this section will be read from this perspective and should not be construed as admitting the content of the prior art or the content that does not exist in the prior art.

[0003] In a communication system, the function for non-Internet Protocol data delivery (NIDD) can be used to handle mobile-originated (MO) and mobile-terminated (MT) communications with a user equipment (UE), where from the perspective of the evolved packet system (EPS), the data for communication is considered unstructured (also referred to as non-IP (Non-Internet Protocol)).

[0004] For example, in a fourth-generation (4G) communication system, it is necessary to establish an association between a service capability server / application server (SCS / AS) and a public data network (PDN) connection to a service capability enabling function (SCEF) to achieve the transmission of non-IP data between a user equipment (UE) and the SCS / AS. When reliable data service is not enabled, the SCEF determines the association based on the provided policy that can be used to map the SCS / AS identifier and the user identifier to an access point name (APN). When reliable data service is enabled, the SCEF determines the association based on the port number and the provided policy that can be used to map the SCS / AS identifier and the user identifier to the APN (see 3rd Generation Partnership Project Technical Specification, 3GPP TS 23.682, V16.4.0, Section 4.5.14.3).

[0005] When more than one SCS / AS is associated with the same PDN connection, packets destined for or from a port number associated with more than one SCS / AS are allowed. In addition, any policy applied to the PDN connection (such as APN rate control) can be applied to the traffic from all SCS / ASs associated with the PDN connection.

[0006] Reliable data service (RDS) can be used to allow data transmission of multiple SCS / ASs (i.e., multiple applications) using the same non-IP PDN connection.

[0007] In addition, when using a PDN connection of PDN type 'non-IP', the User Equipment (UE) and the SCEF or the Packet Data Network Gateway (P-GW) can use the Reliable Data Service. This service provides a mechanism for the SCEF or the P-GW to determine whether the data has been successfully transmitted to the UE, or for the UE to determine whether the data has been successfully transmitted to the SCEF. When the requested acknowledgement is not received, the Reliable Data Service re-transmits the packet. The service is enabled or disabled based on the APN configuration of each Service Level Agreement (SLA).

[0008] When the service is enabled, a protocol is used between the endpoints of the non-IP PDN connection. This protocol uses the packet header to identify whether the packet does not require an acknowledgement, requires an acknowledgement, or is an acknowledgement and allows the detection and elimination of duplicate PDUs at the receiving endpoint. The Reliable Data Service supports single and multiple applications within the UE. The port numbers in the header are used to identify the application on the originator and to identify the application on the receiver. The UE, the SCEF, and the P-GW can support reserving source and destination port numbers for their use and subsequently releasing the reserved port numbers. The Reliable Data Service protocol (as defined in 3GPP TS24.250 V16.1.0) also enables an application to query its peer entity to determine which port numbers are reserved and which are available for use at any given time. SUMMARY OF THE INVENTION

[0009] The present Summary of the Invention is provided to introduce various concepts in a simplified form, which are further described in the Detailed Description. The present Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0010] Currently, static RDS port information is sent to the SCEF through NIDD configuration, etc. Then, the MO / MT non-IP data including any one of the RDS port information is transmitted by the SCEF. However, the SCEF will directly transmit any MO / MT non-IP data, including these NIDD messages with mismatched port numbers. That is, due to the meaningless messages including mismatched port numbers, there will be a waste of communication resources and undesired actions in the communication network.

[0011] Certain aspects and embodiments of the present disclosure can provide solutions to these or other challenges. Various embodiments for solving one or more problems disclosed herein are presented herein. That is, according to the embodiments of the present disclosure, the network resources for sending invalid NIDD data can be saved, and the undesired actions in the communication system can be avoided.

[0012] A first aspect of the present disclosure provides a method performed at a first entity, including: receiving, from a second entity, a non-Internet protocol data delivery (NIDD) message including one or more RDS port numbers; and determining whether the one or more RDS port numbers are in a configured RDS port list.

[0013] In an embodiment of the present disclosure, the one or more RDS port numbers include a source port number and a destination port number. Determining whether the one or more RDS port numbers are in the configured RDS port list may include: determining whether the source port number in the NIDD message is equal to the configured source port number in the configured RDS port list; and / or determining whether the destination port number in the NIDD message is equal to the configured destination port number in the configured RDS port list.

[0014] In an embodiment of the present disclosure, the method further includes: discarding the NIDD message if it is determined that the one or more RDS port numbers are not in the configured RDS port list.

[0015] In an embodiment of the present disclosure, the method further includes: sending a response message including an indication of port number inconsistency if it is determined that the one or more RDS port numbers are not in the configured RDS port list.

[0016] In an embodiment of the present disclosure, the indication of port number inconsistency may include an error code and the value of the port number in the NIDD message.

[0017] In an embodiment of the present disclosure, the response message is sent to a service capability server / application server (SCS / AS) or an application function (AF); the response message includes at least one of the following: a mobile terminated (MT) NIDD submission response message; a group MT NIDD submission response message; an NIDD authorization notification request message; or a mobile originated (MO) NIDD indication message.

[0018] In an embodiment of the present disclosure, the method further includes: receiving an updated configured RDS port list from the SCS / AS or the AF after sending the response message including the indication of port number inconsistency; or receiving an updated NIDD message from the SCS / AS or the AF after sending the response message including the indication of port number inconsistency.

[0019] In an embodiment of the present disclosure, if the RDS port verification feature is supported, the first entity determines whether the one or more RDS port numbers are in the configured RDS port list.

[0020] In an embodiment of the present disclosure, the first entity includes a Service Capability Exposure Function (SCEF) or a Network Exposure Function (NEF); and the second entity includes an SCS / AS or an AF or a terminal device.

[0021] A second aspect of the present disclosure provides a method performed at a second entity, including: sending a NIDD message including one or more RDS port numbers to a first entity. The first entity determines whether the one or more RDS port numbers are in a configured RDS port list.

[0022] In an embodiment of the present disclosure, the one or more RDS port numbers include a source port number and a destination port number. When the first entity determines whether the one or more RDS port numbers are in the configured RDS port list, the first entity determines: whether the source port number in the NIDD message is equal to the configured source port number in the configured RDS port list; and / or whether the destination port number in the NIDD message is equal to the configured destination port number in the configured RDS port list.

[0023] In an embodiment of the present disclosure, if it is determined that the one or more RDS port numbers are not in the configured RDS port list, the first entity discards the NIDD message.

[0024] In an embodiment of the present disclosure, the method further includes: if it is determined that the one or more RDS port numbers are not in the configured RDS port list, receiving, from the first entity, a response message including an indication of port number inconsistency.

[0025] In an embodiment of the present disclosure, the indication of the port number inconsistency may include an error code and the value of the port number in the NIDD message.

[0026] In an embodiment of the present disclosure, the second entity includes an SCS / AS or an AF; and the response message includes at least one of the following: an MT NIDD submission response message; a group MT NIDD submission response message; a NIDD authorization notification request message; or an MO NIDD indication message.

[0027] In an embodiment of the present disclosure, the method further includes: after receiving the response message including the indication of the port number inconsistency, sending an updated configured RDS port list to the first entity; or after receiving the response message including the indication of the port number inconsistency, sending an updated NIDD message to the first entity.

[0028] In an embodiment of the present disclosure, the second entity includes a terminal device.

[0029] In an embodiment of the present disclosure, if the RDS port authentication feature is supported, the first entity determines whether the one or more RDS port numbers are in the configured RDS port list.

[0030] In an embodiment of the present disclosure, the first entity includes an SCEF or a NEF.

[0031] A third aspect of the present disclosure provides a device for a first entity, including: a processor; and a memory containing instructions executable by the processor. The first entity is operable to: receive a NIDD message including one or more RDS port numbers from a second entity; and determine whether the one or more RDS port numbers are in the configured RDS port list.

[0032] In an embodiment of the present disclosure, the first entity is further operable to implement any of the above methods.

[0033] A fourth aspect of the present disclosure provides a device for a second entity, including: a processor; and a memory containing instructions executable by the processor. The second entity is operable to: send a NIDD message including one or more RDS port numbers to a first entity. The first entity determines whether the one or more RDS port numbers are in the configured RDS port list.

[0034] In an embodiment of the present disclosure, the second entity is further operable to implement any of the above methods.

[0035] A fifth aspect of the present disclosure provides a device for a first entity, including: a receiving unit configured to receive a NIDD message including one or more RDS port numbers from a second entity; and a determining unit configured to determine whether the one or more RDS port numbers are in the configured RDS port list.

[0036] In an embodiment of the present disclosure, the first entity is further operable to implement any of the above methods.

[0037] A sixth aspect of the present disclosure provides a device for a second entity, including: a sending unit configured to send a NIDD message including one or more RDS port numbers to a first entity. The first entity determines whether the one or more RDS port numbers are in the configured RDS port list.

[0038] In an embodiment of the present disclosure, the second entity is further operable to implement any of the above methods.

[0039] The seventh aspect of the present disclosure provides a computer-readable storage medium, on which a computer program is stored, where the computer program can be executed by a device to enable the device to execute any of the above methods.

[0040] According to some embodiments of the present disclosure, the port consistency of NIDD messages can be checked. Therefore, network resources used for sending invalid NIDD data can be saved, and undesired actions in the communication system can be avoided.

[0041] In addition, according to some embodiments of the present disclosure, the NIDD service for SCS / AS or AF can be improved (i.e., the 3GPP network can notify abnormal situations to SCS / AS or AF). Description of the Drawings

[0042] Through a more detailed description of some embodiments of the present disclosure in the drawings, the above and other objects, features, and advantages of the present disclosure will become more apparent, where the same reference generally refers to the same components in the embodiments of the present disclosure.

[0043] Figure 1 is an exemplary process diagram of NIDD configuration.

[0044] Figure 2 is an exemplary flowchart showing the method according to an embodiment of the present disclosure.

[0045] Figure 3 is an example diagram showing the address and control field formats for NIDD messages.

[0046] Figure 4 is showing Figure 2 is an exemplary flowchart showing the sub-steps of the method shown in

[0047] Figure 5 is showing Figure 2 is an exemplary flowchart showing the additional steps of the method shown in

[0048] Figure 6 is showing Figure 2 is another exemplary flowchart showing the additional steps of the method shown in

[0049] Figure 7 is an exemplary process for MT NIDD for a single UE.

[0050] Figure 8 is an exemplary process for MT NIDD for a group of UEs.

[0051] Figure 9 is an exemplary process of a mobile-initiated NIDD process.

[0052] Figure 10is an exemplary process of the NIDD authorization update process.

[0053] Figure 11 is a block diagram showing apparatuses for a first and a second entity according to an embodiment of the present disclosure.

[0054] Figure 12 is a block diagram showing a computer-readable storage medium according to an embodiment of the present disclosure.

[0055] Figure 13 is a block diagram showing functional units of an apparatus according to an embodiment of the present disclosure. Detailed Description

[0056] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided only as examples to convey the scope of the subject matter to those skilled in the art.

[0057] In general, all terms used herein will be interpreted according to their ordinary meaning in the relevant technical field, unless clearly given a different meaning and / or implied in the context in which the term is used. All references to an element, apparatus, component, device, step, etc. shall be construed openly as referring to at least one instance of the element, apparatus, component, device, step, etc., unless otherwise explicitly stated. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless explicitly described as after or before another step and / or implicitly one step must be after or before another step. In appropriate cases, any feature of any embodiment disclosed herein can be applied to any other embodiment. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other objectives, features, and advantages of the appended embodiments will be apparent from the following description.

[0058] References to features, advantages, or similar language throughout the specification do not imply that all features and advantages that can be realized with the present disclosure should be or are in any single embodiment of the present disclosure. Rather, language referring to features and advantages should be understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Additionally, the described features, advantages, and characteristics of the present disclosure can be combined in any suitable manner in one or more embodiments. Those skilled in the relevant art will recognize that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized that may not be present in all embodiments of the present disclosure.

[0059] As used herein, the term "network" or "communication network / system" refers to a network / system that complies with any suitable communication standard (such as New Radio (NR), Long-Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), etc.). In addition, the communication between the terminal device and the network node in this communication network can be carried out according to any suitable generation of communication protocol (including but not limited to the first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), 4G, 4.5G, 5G communication protocols and / or any other protocol known currently or to be developed in the future).

[0060] The terms "entity", "network entity", "network function" may refer to a network device / apparatus / node having access capabilities in a communication network, through which a terminal device accesses the network and receives services therefrom. The entity / function may include a base station (BS), an access point (AP), a multi-cell / multicast coordination entity (MCE), a server node / function (such as a service capability server / application server (SCS / AS), a group communication service application server (GCS AS), an application function (AF)), an open node (such as a service capability exposure function (SCEF), a network exposure function (NEF), a controller or any other suitable device in a radio communication network. The BS may be, for example, a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next-generation Node B (gNodeB or gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, a low-power node such as a femto node, a pico node, etc.

[0061] Further examples of network functions / entities include a multi-standard radio (MSR) radio device (such as an MSR BS), a network controller (such as a radio network controller (RNC) or a base station controller (BSC)), a base transceiver station (BTS), a transmission point, a transmission node, a positioning node, etc. However, more generally, a network node may represent any suitable device (or group of devices) capable of, configured to, arranged to, and / or operable to enable and / or provide access of a terminal device to a wireless communication network or to provide certain services to a terminal device already accessing the wireless communication network.

[0062] The term terminal device covers a device capable of communicating with a network function / node such as a base station or with another wireless device by sending and / or receiving wireless signals. Thus, the term terminal device includes but is not limited to: mobile phones, stationary or mobile wireless devices for machine-to-machine communication, integrated or embedded wireless cards, externally inserted wireless cards, vehicles, etc.

[0063] As yet another specific example, in an Internet of Things (IoT) scenario, a terminal device can also be referred to as an IoT device and represents a machine or other device that performs monitoring, sensing, and / or measurement, etc. and transmits the results of such monitoring, sensing, and / or measurement, etc. to another terminal device and / or network device. In this case, the terminal device can be a machine-to-machine (M2M) device, which can be referred to as a machine type communication (MTC) device in the context of the 3rd Generation Partnership Project (3GPP).

[0064] As a specific example, the terminal device can be a user equipment UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (such as power meters), industrial machinery, or household or personal appliances (e.g., refrigerators, televisions), personal wearable devices (such as watches), etc. In other cases, the terminal device can represent a vehicle or other device (such as a medical device) capable of monitoring, sensing, and / or reporting its operating state or other functions associated with its operation.

[0065] As used herein, the terms "first", "second", etc. refer to different elements. Unless the context clearly indicates otherwise, the singular forms "a" and "an" are also intended to include the plural forms. As used herein, the terms "comprising", "including", "having", and / or "containing" specify the presence of the stated features, elements, and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. The term "based on" should be understood as "at least partially based on". The terms "an embodiment" and "embodiments" should be understood as "at least one embodiment". The term "another embodiment" should be understood as "at least one other embodiment". Other definitions (explicit and implicit) may be included hereinafter.

[0066] Figure 1 is an exemplary process diagram for NIDD configuration.

[0067] Figure 1 identical to " Figure 5 .13.2-1: Configuration for the NIDD procedure" in 3GPP TS 23.682 V16.4.0 (see Section 5.13.2 of 3GPP TS 23.682 V16.4.0 for more details, the entire content of which is incorporated herein by reference). Figure 1The configuration process shown applies to a single UE and a group of UEs. Referring to 3GPP TS 23.682 V16.4.0, Section 5.13.2, in step 1, the SCS / AS sends a NIDD configuration request message to the SCEF. In step 2, if the requested action is set to "cancel", it indicates that the purpose of the request is to cancel the transaction identified by the TL TRI (T8 long-term transaction reference ID), and the process proceeds to step 6. If the requested action is set to "update", the purpose of the transaction is to update the parameters associated with the configuration. In step 3, the SCEF sends a NIDD authorization request (external group identifier, external identifier, or MSISDN, APN, MTC provider information) to the HSS (Home Subscriber Server) to authorize the NIDD configuration request for the UE belonging to the external group identifier, received external identifier, or MSISDN, and if necessary, will receive the necessary information for NIDD. In step 4, the HSS checks the NIDD authorization request message for the existence of, for example, the external group identifier, external identifier, or MSISDN. In step 5, the HSS sends a NIDD authorization response (result with a single value or a list (IMSI and MSISDN or external identifier)) message to the SCEF to confirm acceptance of the NIDD authorization request. In step 6, the SCEF sends a NIDD configuration response (TLTRI, maximum packet size, reliable data service indication, and cause) message to the SCS / AS to confirm acceptance of the NIDD configuration request and delete the identified NIDD configuration (if requested).

[0068] In this NIDD configuration process, the SCS / AS may send a list of RDS ports in the RDS configuration. These ports will be used for subsequent non-IP data transfer.

[0069] Static RDS port information may be sent via NIDD configuration, as Figure 1 shown. Alternatively, by introducing a dynamic RDS port management process between the UE and the SCEF (refer to 3GPP TS 24.250 V16.1.0, the entire content of which is incorporated herein by reference), the SCS / AS may (via the SCEF) negotiate with the UE dynamically regarding RDS port reservation / release.

[0070] However, the SCEF does not verify the received RDS ports, i.e., whether it aligns with the subsequent received MO / MT non-IP data.

[0071] Then, it is possible that the RDS ports included in the MO / MT NIDD are not set / configured by the previous NIDD configuration. If there is a mismatch for the MO NIDD, if received from the UE, the MO data may be silently discarded by the SCEF; for the MT NIDD, the MT data can be transmitted to the UE but is silently discarded by the UE due to the unknown RDS port (i.e., unknown application).

[0072] Therefore, unwanted data such as MT NIDD with mismatched port information is still transmitted, wasting communication resources and causing unwanted and unpredictable actions in the communication network.

[0073] Figure 2 is an exemplary flowchart showing a method according to an embodiment of the present disclosure.

[0074] As Figure 2 shown, the method performed at the first entity 100 may include: step S101, receiving a non-Internet protocol data delivery (NIDD) message including a port number, particularly one or more RDS port numbers, from the second entity; and step S102, determining whether the one or more RDS port numbers are consistent with the NIDD configuration. In particular, the NIDD configuration may include a configured list of RDS ports. It can be determined whether the one or more RDS port numbers are in the configured list of RDS ports.

[0075] In an embodiment of the present disclosure, the first entity 100 may include any entity capable of receiving NIDD data during the NIDD process in a communication system. For example, the first entity 100 may include the SCEF as Figure 1 shown, or a network exposure function (NEF) in a fifth-generation (5G) communication system.

[0076] The method performed at the second entity 200 may include: step S201, sending a NIDD message including a port number (e.g., one or more RDS port numbers) to the first entity. The first entity determines whether the port number is consistent with the NIDD configuration (e.g., whether the one or more RDS port numbers are in the configured list of RDS ports).

[0077] In an embodiment of the present disclosure, the second entity 200 may include any entity capable of sending NIDD data during the NIDD process in a communication system. For example, the second entity 100 may include the SCS / AS as Figure 1 shown, an application function (AF) in a 5G system, or a terminal device, such as any UE.

[0078] According to an embodiment of the present disclosure, the first entity 100 may check the port consistency between any received NIDD message and the NIDD configuration. Therefore, network resources used for sending invalid NIDD data can be saved, and undesired actions in the communication system can be avoided.

[0079] Figure 3 FIG. is an example diagram showing the address and control field formats for NIDD messages. Figure 3 is the same as 3 in GPP TS 24.250, V16.1.0, " Figure 5 .2.1-1: Address and Control Field Formats". The I-frame may be for information transfer for confirmation; the S-frame may be for supervision functions; the UI-frame may be for unacknowledged information transfer; the U-frame may be for control functions. The description of the bits in Figure 3 may be as follows: A is for the acknowledgment request bit; Mn is for the non-digital function bit; N(R) is for the receive sequence number; N(S) is for the transmit sequence number; N(U) is for the unacknowledged sequence number; Sn is for the supervision function bit; Rn is for the selective acknowledgment bit map bit; PD is for the protocol discriminator bit; C / R is for the command / response bit; ADS is for the address bit; the source port is for the source port number; the destination port is for the destination port number; X is for the spare bit.

[0080] As Figure 3 shown, in an embodiment of the present disclosure, the port number includes the source port number and / or the destination port number. In particular, the port number may include: the RDS source port number and / or the RDS destination port number.

[0081] According to an embodiment of the present disclosure, a strict policy may be applied to check the port consistency. That is, if any one of the source port or the destination port in the NIDD message is not equal to the configured one in the NIDD configuration, it will be determined that the port number is inconsistent with the NIDD configuration.

[0082] In addition, the first entity 100 may obtain the port number from the NIDD configuration and the NIDD message based on the applied standards or technical specifications. For example, the same exemplary Table 1 as in Table 5.6.2.2.2-1 in section 5.6.2.2.2 of 3GPP TS 29.122 V16.3.0, which is incorporated herein by reference in its entirety, shows the definition of Rdsport, the port configuration for reliable data transfer.

[0083] Table 1: Definition of the RdsPort data type

[0084]

[0085] Referring further to Section 5.2.4 of 3GPP TS 24.250 V16.1.0, when a UE application starts to send RDS frames using a PDN connection or a PDU session, the UE and the network establish which source port number will be used for the application on the UE side for MO services and which destination port number will be used for the application intended to receive frames on the network side. Similarly, for MT services, when an application in the network starts to send RDS frames using a PDN connection or a PDU session, the UE and the network establish which source port number will be used for the application on the network side and which destination port number will be used for the application intended to receive frames on the UE side.

[0086] Figure 4 is shown Figure 2 an exemplary flowchart of sub-steps of the method shown in

[0087] As Figure 4 shown, step S102 of determining whether the port numbers are consistent with the NIDD configuration may include: step S1021 of determining whether the source port number in the NIDD message is equal to the configured source port number in the NIDD configuration (specifically in the configured RDS port list); and / or step S1022 of determining whether the destination port number in the NIDD message is equal to the configured destination port number in the NIDD configuration.

[0088] For example, for MT NIDD, when receiving an MT NIDD message, the SCEF should check whether the received RDS destination port is equal to the configured RDS port on the UE and whether the received RDS source port is equal to the configured RDS port on the SCEF. If there is any mismatch, the SCEF will report an error.

[0089] For MO NIDD, after decoding the RDS source port and destination port from an RDS I-format frame or a UI-format frame as Figure 3 shown. The SCEF will check whether the decoded RDS destination port is equal to the configured RDS port on the SCEF and whether the decoded RDS source port is equal to the configured RDS port on the UE. If there is any mismatch, the SCEF should report an error.

[0090] Figure 5 is shown Figure 2 an exemplary flowchart of additional steps of the method shown in

[0091] In an embodiment of the present disclosure, the method executed at the first entity 100 further includes: step S103 of discarding the NIDD message if it is determined that the port numbers are inconsistent with the NIDD configuration.

[0092] In addition, in an embodiment of the present disclosure, the method performed at the first entity 100 further includes: step S104, if it is determined that the port number is inconsistent with the NIDD configuration, send a response message including an indication of the port number inconsistency (e.g., indicating that the port number is unknown).

[0093] In an embodiment of the present disclosure, the method performed at the second entity 200 further includes: step S204, if it is determined that the port number is inconsistent with the NIDD configuration, receive from the first entity a response message including an indication of the port number inconsistency.

[0094] In an embodiment of the present disclosure, the indication of the port number inconsistency may include an error code and the value of the port number in the NIDD message.

[0095] According to an embodiment of the present disclosure, network resources for sending invalid MT NIDD are saved. In addition, an improved NIDD service can be provided (i.e., the 3GPP network can notify the second entity, such as the SCS / AS or AF, of the abnormal situation).

[0096] In an embodiment of the present disclosure, the response message for the abnormal situation can be any type of message / signaling, and the indication for the abnormal situation can be any type of indicator / flag / information element.

[0097] For example, when the response message is sent to the service capability server / application server (SCS / AS) or the application function, the response message may include at least one of the following: a mobile terminated (MT) NIDD submission response message; a group MT NIDD submission response message; a NIDD authorization notification request message; or a mobile originated (MO) NIDD indication message.

[0098] Figure 6 is shown Figure 2 Another exemplary flowchart showing additional steps of the method shown in

[0099] In an embodiment of the present disclosure, the method performed at the first entity 100 further includes: S105, after sending the response message including the indication of the port number inconsistency, receive an updated NIDD configuration from the SCS / AS or AF; or S106, after sending the response message including the indication of the port number inconsistency, receive an updated NIDD message from the SCS / AS or AF.

[0100] In an embodiment of the present disclosure, the method performed at the second entity 200 further includes: S205, after receiving the response message including the indication of the port number inconsistency, send an updated NIDD configuration to the first entity; or S206, after receiving the response message including the indication of the port number inconsistency, send an updated NIDD message to the first entity.

[0101] For example, if it is determined that the port number is inconsistent with the NIDD configuration, the first entity 100 (such as an SCEF) sends an 'RDS port unknown' error message to the second entity 200 (such as an SCS / AS). Then, after receiving the 'RDS port unknown' error message, the second entity 200 will perform at least one of the following corrective actions:

[0102] - Reconfigure the NIDD with the correct RDS port information (for static RDS port configuration) or reconfigure with the correct RDS port information in the RDS port management (for dynamic RDS port configuration);

[0103] - Use the correct port for further MT NIDD according to the RDS configuration;

[0104] - Reconfigure the UE with the correct RDS port (e.g., via over-the-air (OTA)).

[0105] Figure 7 This is an exemplary process for the MT NIDD of a single UE. Figure 7 With 3 Section 5.13.3 in GPP TS 23.682 V16.4.0, " Figure 5.13.3-1: The MT NIDD procedure is the same. See Section 5.13.3 of 3GPP TS 23.682 V16.4.0. In step 1, if the SCS / AS has activated the NIDD service for a given UE and has downlink non-IP data to send to the UE, the SCS / AS sends an MT NIDD submission request (external identifier or MSISDN, TLTRI, non-IP data, non-IP data sequence number, reliable data service configuration, maximum delay, priority, PDN connection establishment option) message to the SCEF. In step 2, the SCEF determines the EPS bearer context based on the APN associated with the NIDD configuration and the user identity. In step 3, if an SCEF EPS bearer context corresponding to the external identifier or MSISDN included in step 1 is found, the SCEF sends an NIDD submission request (user identity, EPS bearer ID, SCEF ID, non-IP data, SCEF waiting time, maximum retransmission time) message to the MME / SGSN. In step 4, if the MME / SGSN can immediately deliver the non-IP data to the UE, for example when the UE is already in the ECM_CONNECTED mode, or the UE is in ECM_IDLE and the MME / SGSN is able to initiate a paging procedure (see TS 23.401 [7]), the procedure proceeds to step 8. If the MME / SGSN knows that the UE is temporarily unreachable, or if the MME / SGSN knows that the UE is not scheduled to be reachable within the SCEF waiting time when using power saving functions such as UE power saving mode (see Section 4.5.4) or extended idle mode DRX (see Section 4.5.13), the MME / SGSN may send an NIDD submission response (cause, requested retransmission time) message to the SCEF. In step 5, the SCEF may send an MT NIDD submission response (requested retransmission time, non-IP data sequence number, buffering indication, cause) to the SCS / AS, notifying the reception result from the MME / SGSN. In step 6, when the MME / SGSN detects that the UE is reachable (e.g., when coming out of the PSM mode by performing a TAU / RAU, when initiating MO communication, etc.), or when the UE is about to become reachable (e.g., the extended idle mode DRX cycle expires, the MME / SGSN predicts the MO communication mode for the UE, etc.) and the MME / SGSN has the Not Reachable for NIDD flag set, the MME / SGSN sends an NIDD submission indication (user identity) message to the SCEF.In step 7, if the data has not been purged, the SCEF sends a NIDD submission request (user identifier, EPS bearer ID, SCEF ID, non-IP data, SCEF wait time, maximum retransmission time) message to the MME / SGS. In step 8, if necessary, the MME / SGSN pages the UE and transmits the non-IP data to the UE using the data transmission described in Section 5.3.4B.3 of TS 23.401 [7] for the MME procedure or Sections 9.3 and 9.6 of TS 23.060 [6] for the SGSN procedure. Depending on the operator configuration, the MME / SGSN may generate the necessary accounting information required for charging. In step 9, if the MME / SGSN is able to initiate step 8, the MME / SGSN sends a NIDD submission response (cause) message to the SCEF, confirming the NIDD submission request received from the SCEF in step 3 or step 7. In step 10, the SCEF sends an MT NIDD submission response (reliable data service confirmation indication, hop-by-hop confirmation indication, non-IP data sequence number, cause).

[0106] According to an embodiment of the present disclosure, steps 2a and 2b in Figure 7 can be improved.

[0107] For example, in 2a, if a new feature for checking port consistency is supported, the SCEF may check / verify whether the received RDS port in the MT NIDD is identified based on the NIDD configuration. If the above check fails, the SCEF shall reject the request in 2b (MT NIDD submission response message) using a new error code (e.g., "RDS port unknown").

[0108] Specifically, as an exemplary improvement (underlined part) for "3GPP TS 29.122 V16.3.0, 4.4.5.3.1 Mobile Terminated NIDD for a Single UE", when receiving an HTTP POST request for downlink data transfer for a single UE from the SCS / AS, the SCEF shall:... If the Rds_port_check / verification function is supported, check whether the RDS port number is configured (e.g., whether the RDS port number is in the configured RDS list). If the RDS port number is unknown in SCEF, then SCEF shall reply with a 403 Forbidden response, which has a cause value of "RDS_PORT_UNKNOWN" (RDS_ port_ unknown) in the "cause" attribute of the "ProblemDetails" (problem details) structure (e.g., to indicate that the RDS port is not correctly configured) Figure 8 .

[0109] Figure 8 is an exemplary procedure for MT NIDD for a group of UEs. Figure 8 With 3 in Section 5.5.3 of GPP TS 23.682 V16.4.0 " Figure 5.5.3-1: Group Message Transfer via Unicast MT NIDD". Refer to Section 5.5.3 of 3GPP TS 23.682 V16.4.0. In step 1, if the SCS / AS has downlink non-IP data to send to a group of UEs, the SCS / AS sends a group MT NIDD submission request (SCS / AS identifier, external group identifier, TL TRI, non-IP data, reliable data service configuration, maximum latency, PDN connection establishment option) message to the SCEF. In step 2, based on the previous NIDD configuration of the UE group (refer to Section 5.13.2) and the list of authorized external identifiers associated with the external group identifier stored in the SCEF, the SCEF sends a single group MT NIDD submission response (reason) message to the SCS / AS to confirm acceptance of the group MT NIDD submission request. In step 3, for each external identifier belonging to the external group identifier, the SCEF executes this step. The SCEF stores the list of authorized external identifiers associated with the external group identifier during the previous NIDD configuration of the UE group (refer to Section 5.13.2). In step 4, after executing step 3 for all UEs, the SCEF sends an aggregated response message group MT NIDD submission indication (TLTRI associated with the request in step 1, hop-by-hop confirmation indication, retransmission time, trigger indication, reason).

[0110] According to an embodiment of the present disclosure, the steps in Figure 8 can be improved.

[0111] For example, after checking the RDS port in the group MT NIDD submission request and if the SCEF does not know the RDS port (if the new feature is supported), the SCEF needs to reject the request in step 2 (group MT NIDD submission response message) using the new error code 'RDSPORT UNKNOWN (RDS port unknown)'.

[0112] Specifically, as an exemplary improvement (underlined part) to "4.4.5.3.2 Mobile Terminated NIDD for a Group of UEs in 3GPP TS 29.122 V16.3.0", after receiving such an HTTP POST request from the SCS / AS requesting group message transfer, the SCEF checks whether the SCS / AS is authorized to send NIDD requests, whether the non-IP packet size is greater than the maximum packet size provided to the SCS / AS during NIDD configuration, and If the Rds_port_check feature is supported, whether the RDS port number is recognized recognized .

[0113] Figure 9 is an exemplary process of the mobile originated NIDD procedure. Figure 9 With 3The same as " Figure 5 .13.4-1: Mobile originated NIDD procedure" in section 5.13.4 of GPP TS 23.682 V16.4.0. See section 5.13.4 of GPP TS 23.682 V16.4.0. In step 1, the UE sends a NAS message with EPS bearer ID and non-IP data to the MME according to the procedure (steps 0-2) described in section 5.3.4B.2 of TS 23.401 [7], including the reliable data service header if reliable data service is enabled, or the UE sends data to the SGSN on a PDN type non-IP PDP context associated with the T6b interface (see sections 9.3 and 9.6 of TS23.060 [6]). In step 2, the MME / SGSN sends a NIDD submission request (user identification, EBI, SCEF ID, non-IP data, MO exception data counter) message to the SCEF. In a roaming scenario, the MME / SGSN sends this message to the IWK-SCEF, and the IWK-SCEF forwards this message to the SCEF via T7. In step 3, when the SCEF receives non-IP data on the T6a / T6b (or T7) interface and finds the SCEF EPS bearer context and the associated T8 destination address, it sends the non-IP data to the SCS / AS identified by the T8 destination address indicated in the MONIDD (external identifier or MSISDN, non-IP data, TL TRI, reliable data service configuration). In step 4, the SCS / AS responds to the SCEF with a MO NIDD confirmation (reason). In step 5, the SCEF sends a NIDD submission response to the MME / SGSN.

[0114] According to an embodiment of the present disclosure, the procedure between step 2 and step 3 in Figure 9 the MO NIDD can be improved.

[0115] For example, if the new feature is supported, the SCEF should check whether the RDS port in the MO non-IP data is recognized.

[0116] If it is not recognized, the SCEF should notify all SCS / AS in step 3 (MO NIDD message). Alternatively, the SCEF can trigger the NIDD authorization notification procedure described below to notify all SCS / AS.

[0117] Figure 10 is an exemplary procedure of the NIDD authorization update procedure.

[0118] According to an embodiment of the present disclosure, in Figure 10In step 1 therein, the SCEF may initially send a NIDD authorization notification request using the new NIDD status 'RDSPORT UNKNOWN (RDS port unknown)' and an unrecognized RDS port. In step 2, the SCEF may receive a NIDD authorization notification response from the SC / AS.

[0119] Specifically, as an improvement to "4.4.5.5 NIDD authorization update procedure in 3GPP TS 29.122 V16.3.0" (underlined part), If the Rds_port_check feature is supported, before sending an MO MO NIDD to SCS / AS as specified in Section 4.4.5.4, SCEF shall check the (decoded) RDS port number contained in the uplink non-IP data. If it is not in the configured RDS port list, then SCEF shall notify all SCS / AS with an NIDD status set to "RDS_PORT_UNKNOWN" and an unknown (i.e., unrecognized) RDS port number. SCS / AS shall confirm the request with an HTTP 200 OK or 204 No Content response. Confirm the request.

[0120] Table 2 shows an exemplary improvement (underlined part) to the "definition of Table 5.6.2.1.6-1: Type NiddConfigurationStatusNotification (Nidd configuration status notification) in Section 5.6.2.1.6 of 3GPP TS 29.122 V16.3.0" according to an embodiment of the present disclosure.

[0121] Table 2: Definition of Type NiddConfigurationStatusNotification

[0122]

[0123]

[0124] Table 3 shows an exemplary improvement (underlined part) to the "Table 5.6.2.3.5-1: Enumeration NiddStatus in Section 5.6.2.3.5 of 3GPP TS 29.122 V16.3.0" according to an embodiment of the present disclosure.

[0125] Table 3: Enumeration NiddStatus

[0126]

[0127] Table 4 shows an exemplary improvement (underlined part) to the "Table 5.6.5.3-1: Application Error in Section 5.6.5.3 of 3GPP TS 29.122 V16.3.0" according to an embodiment of the present disclosure.

[0128] Table 4: Application Error

[0129]

[0130]

[0131] In addition, exemplary improvements (underlined) to the "A.6 NIDD API in 3GPP TS 29.122 V16.3.0" are also shown below.

[0132] (... text not shown for clarity......)

[0133]

[0134]

[0135] (... text not shown for clarity......)

[0136]

[0137]

[0138] Figure 11 It is a block diagram showing devices of a first entity and a second entity according to an embodiment of the present disclosure.

[0139] As Figure 11 shown, the device for the first entity 100 may include: a processor 110; and a memory 120 containing instructions executable by the processor 110. The first entity 100 is operable to: receive a NIDD message including a port number from the second entity; and determine whether the port number is consistent with the NIDD configuration.

[0140] In an embodiment of the present disclosure, the first entity is further operable to implement any of the above methods, such as Figure 1 - 10 the method shown.

[0141] As Figure 11 shown, the device for the second entity 200 may include: a processor 210; and a memory 220 containing instructions executable by the processor 210. The second entity 200 is operable to: send a NIDD message including a port number to the first entity. The first entity determines whether the port number is consistent with the NIDD configuration.

[0142] In an embodiment of the present disclosure, the second entity is further operable to implement any of the above methods, such as Figure 1 - 10 the method shown in

[0143] The processor 110 and the processor 210 can be any type of processing components, such as one or more microprocessors or microcontrollers, as well as other digital hardware, which may include a digital signal processor (DSP), dedicated digital logic, and so on. The memories 120 and 220 can be any type of storage components, such as read-only memory (ROM), random access memory, cache memory, flash memory devices, optical storage devices, etc.

[0144] Figure 12 is a block diagram showing a computer-readable storage medium according to an embodiment of the present disclosure.

[0145] As Figure 12 shown, a computer-readable storage medium 1000 having a computer program 1001 stored thereon. The computer program 1001 is executable by an entity to cause the entity to perform any of the above methods, such as [[ID= the method shown.

[0146] The computer-readable storage medium 1000 can be configured to include a memory, such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, floppy disks, hard disks, removable cartridge memories, or flash drives.

[0147] ​ is a block diagram showing functional units of a device according to an embodiment of the present disclosure.

[0148] As ​ shown, the device for the first network entity 100 may include: a receiving unit 101 configured to receive an NIDD message including a port number from a second entity; and a determining unit 102 configured to determine whether the port number is consistent with the NIDD configuration.

[0149] In an embodiment of the present disclosure, the first entity 100 is also operable to implement any of the above methods, such as ​ the method shown in

[0150] As ​ shown, the device for the second entity 200 may include: a sending unit 201 configured to send an NIDD message including a port number to the first entity. The first entity determines whether the port number is consistent with the NIDD configuration.

[0151] In an embodiment of the present disclosure, the second entity 200 is also operable to implement any of the above methods, such as ​ the method shown in

[0152] A term unit / functional unit may have a conventional meaning in the field of electronics, electrical equipment, and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical entities, and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, outputs, and / or display functions, etc., as those described herein.

[0153] With these units, the apparatus for the first entity 100 or the second entity 200 may not require a fixed processor or memory, and any computing resources and storage resources can be arranged from at least one network node / device / entity / device in the communication system. Virtualization technologies and network computing technologies can be further introduced to improve the utilization efficiency of network resources and the flexibility of the network. In particular, these network entities such as the first entity 100 or the second entity 200 can be implemented as network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on a suitable platform such as a cloud infrastructure.

[0154] According to embodiments of the present disclosure, a new error code indicating 'RDS port unknown' in the MT NIDD response can be supported. An NIDD configuration notification for notifying the SCS / AS of 'RDS port unknown' can be supported. This improvement is applicable to 4G with SCS / AS and SCEF, and also applicable to 5G with AF and NEF.

[0155] Therefore, the NIDD service for the SCS / AS is improved (i.e., the 3GPP network can notify abnormal situations).

[0156] In general, various exemplary embodiments of the present disclosure can be implemented using hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects can be implemented using hardware, while other aspects can be implemented using firmware or software executable by a controller, microprocessor, or other computing device, but the present disclosure is not limited thereto. Although the various aspects of the exemplary embodiments of the present disclosure can be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, apparatuses, systems, technologies, or methods described herein can be implemented as non-limiting examples using hardware, software, firmware, dedicated circuits or logic, general hardware or a controller or other computing device, or some combination thereof.

[0157] Accordingly, it should be understood that at least some aspects of the exemplary embodiments of the present disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be understood that the exemplary embodiments of the present disclosure may be implemented in a device embodied as an integrated circuit, where the integrated circuit may include circuitry (and possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, a baseband circuit, and a radio frequency circuit that are configurable to operate in accordance with the exemplary embodiments of the present disclosure.

[0158] It should be understood that at least some aspects of the exemplary embodiments of the present disclosure may be embodied in computer-executable instructions executed by one or more computers or other devices, such as in one or more program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer-executable instructions may be stored on a computer-readable medium such as a hard disk, an optical disk, a removable storage medium, a solid-state memory, a RAM, etc. Those skilled in the art will understand that the functions of the program modules may be combined or distributed as needed in various embodiments. Additionally, the functions may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field-programmable gate arrays (FPGAs), etc.

[0159] The present disclosure includes any novel feature or combination of features or any generalization thereof explicitly disclosed herein. Various modifications and adaptations of the foregoing exemplary embodiments of the present disclosure will become apparent to those skilled in the relevant arts when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of the present disclosure.

Claims

1. A method performed at a first entity (100), comprising: Receiving (S101) from a second entity a non-Internet Protocol data transfer (NIDD) message comprising one or more reliable data service (RDS) port numbers; Determining (S102) whether the one or more RDS port numbers are in a configured RDS port list; And If it is determined that the one or more RDS port numbers are not in the configured RDS port list, sending (S104) a response message to the second entity (200), the response message comprising an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN (RDS port unknown) in a cause attribute of a "problemDetails" (problem details) structure of the response message.

2. The method according to claim 1, Among them, The one or more RDS port numbers include a source port number and a destination port number; And Wherein determining whether the one or more RDS port numbers are in the configured RDS port list includes: Determining (S1021) whether the source port number in the NIDD message is equal to a configured source port number in the configured RDS port list; and / or Determining (S1022) whether the destination port number in the NIDD message is equal to a configured destination port number in the configured RDS port list.

3. The method according to claim 1 or 2, further comprising: If it is determined that the one or more RDS port numbers are not in the configured RDS port list, discarding (S103) the NIDD message.

4. The method according to claim 1 or 2, Among them, The response message is sent to a service capability server / application server (SCS / AS) or an application function (AF); and Wherein the response message includes at least one of the following: A mobile termination non-Internet Protocol data transfer (MT NIDD) submission response message; A group MT NIDD submission response message; A NIDD authorization notification request message; or A mobile originated non-Internet Protocol data transfer (MO NIDD) indication message.

5. The method according to claim 4, further comprising: After sending the response message comprising the indication of the port number inconsistency, receiving (S105) an updated configured RDS port list from the SCS / AS or the AF; Or After sending the response message comprising the indication of the port number inconsistency, receiving (S106) an updated NIDD message from the SCS / AS or the AF.

6. The method according to any one of claims 1 to 2, Among them, If the RDS port verification feature is supported, the first entity (100) determines whether the one or more RDS port numbers are in the configured RDS port list.

7. The method according to any one of claims 1 to 2, Among them, The first entity includes a service capability exposure function (SCEF) or a network exposure function (NEF); and Wherein, the second entity includes SCS / AS or AF, or a terminal device.

8. A method performed at a second entity (200), comprising: Sending a NIDD message including one or more RDS port numbers to a first entity (S201); Wherein, the first entity determines whether the one or more RDS port numbers are in the configured RDS port list; If it is determined that the one or more RDS port numbers are not in the configured RDS port list, receiving (S204) a response message from the first entity (100), the response message containing an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN (i.e., RDS port unknown) in the cause attribute of the "problemDetails" (i.e., problem details) structure of the response message.

9. The method according to claim 8, Among them, The one or more RDS port numbers include a source port number and a destination port number; and Wherein, when the first entity determines whether the one or more RDS port numbers are in the configured RDS port list, the first entity determines: Whether the source port number in the NIDD message is equal to the configured source port number in the configured RDS port list; and / or Whether the destination port number in the NIDD message is equal to the configured destination port number in the configured RDS port list.

10. The method according to claim 8 or 9, Among them, If it is determined that the one or more RDS port numbers are not in the configured RDS port list, the first entity discards the NIDD message.

11. The method according to claim 8, wherein The indication of the inconsistent port numbers includes an error code and the values of the port numbers in the NIDD message.

12. The method according to claim 8 or 9, Among them, The second entity includes SCS / AS or AF; and Wherein, the response message includes at least one of the following: MT NIDD submission response message; Group MT NIDD submission response message; NIDD authorization notification request message; or MO NIDD indication message.

13. The method according to any one of claims 8 to 9, further comprising: After receiving the response message including the indication of the inconsistent port numbers, sending (S205) an updated configured RDS port list to the first entity; or After receiving the response message including the indication of the inconsistent port numbers, sending (S206) an updated NIDD message to the first entity.

14. The method according to any one of claims 8 to 9, wherein The second entity includes a terminal device.

15. The method according to any one of claims 8 to 9, wherein If the RDS port verification feature is supported, the first entity determines whether the one or more RDS port numbers are in the configured RDS port list.

16. The method according to any one of claims 8 to 9, wherein, The first entity includes SCEF or NEF.

17. An apparatus for a first entity (100), comprising: A processor (110); And A memory (120) containing instructions executable by the processor (110); Wherein, the first entity (100) is operable to: Receive a NIDD message including one or more RDS port numbers from a second entity; Determine whether the one or more RDS port numbers are in the configured RDS port list; and If it is determined that the one or more RDS port numbers are not in the configured RDS port list, send a response message to the second entity (200), the response message including an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN in the cause attribute of the "problemDetails" structure of the response message.

18. The device according to claim 17, wherein The first entity (100) is further operable to implement the method according to claim 2.

19. An apparatus for a second entity (200), comprising: A processor (210); And A memory (220) containing instructions executable by the processor (210); Wherein, the second entity (200) is operable to: Send a NIDD message including one or more RDS port numbers to a first entity; Wherein, the first entity determines whether the one or more RDS port numbers are in the configured RDS port list; and If it is determined that the one or more RDS port numbers are not in the configured RDS port list, receive a response message from the first entity (100), the response message including an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN in the cause attribute of the "problemDetails" structure of the response message.

20. The apparatus according to claim 19, wherein, The second entity (200) is further operable to implement the method according to claim 9.

21. An apparatus for a first entity (100), comprising: A receiving unit (101) configured to receive a NIDD message including one or more RDS port numbers from a second entity; A determining unit (102) configured to determine whether the one or more RDS port numbers are in the configured RDS port list; And A sending unit configured to, if it is determined that the one or more RDS port numbers are not in the configured RDS port list, send a response message to the second entity (200), the response message including an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN in the cause attribute of the "problemDetails" structure of the response message.

22. The device according to claim 21, wherein, The first entity (100) is further operable to implement the method according to claim 2.

23. An apparatus for a second entity (200), comprising: A sending unit (201) configured to send a NIDD message including one or more RDS port numbers to a first entity; wherein the first entity determines whether the one or more RDS port numbers are in a configured RDS port list; and a receiving unit configured to, if it is determined that the one or more RDS port numbers are not in the configured RDS port list, receive a response message from the first entity (100), the response message including an indication that the one or more RDS port numbers are unknown in the first entity (100), wherein the indication includes a cause value indicating RDS_PORT_UNKNOWN (i.e., RDS port unknown) in a cause attribute of a "problemDetails" (i.e., problem details) structure of the response message.

24. The apparatus according to claim 23, wherein, The second entity (200) is further operable to implement the method according to claim 9.

25. A computer-readable storage medium (1000) having a computer program (1001) stored thereon, wherein, The computer program (1001) can be executed by a device to cause the device to execute the method according to any one of claims 1 to 16.

Images