Dynamic control of property of response to update request

Abstract

A method for an initiator entity of a communication system, e.g. a Network Function (NF) service consumer, to specify a response property for an update request message sent to a responder entity, e.g.

Description

Field Various example embodiments relate to dynamic control of a property of a response (message) to an update request (message). More specifically, measures / mechanisms (including methods, apparatuses (i.e. devices, entities, elements, instances and / or functions) and computer program products) are described for enabling / realizing dynamic control of a property of a response (message) to an update request (message) in a communication system. Background Various example embodiments relate to considerations in a (e.g. mobile / wireless) communication system, such as a 5G / NR system and a next-generation system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system of Release 18 onwards. Such considerations may relate to the handling of a resource update request from an initiator entity to a responder entity and a related response message from the responder entity to the initiator entity. Summary Various example embodiments address at least part of issues, problems and / or drawbacks described herein or recognized by a person skilled in the art. Various example embodiments are set out in the claims According to an example embodiment, there is provided a method of (or, stated in other words, operable or for use in / by) an initiator entity of a communication system, the method comprising: specifying a response property as a preferred or required content and / or type of a response message to an update request message, and issuing an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) an initiator entity of a communication system, the apparatus comprising: means for specifying a response property as a preferred or required content and / or type of a response message to an update request message, and means for issuing an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) an initiator entity of a communication system, the apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: specify a response property as a preferred or required content and / or type of a response message to an update request message, and issue an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) an initiator entity of a communication system, the apparatus comprising: circuitry configured to specify a response property as a preferred or required content and / or type of a response message to an update request message, and circuitry configured to issue an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. According to various developments / modifications, any one or more of the aforementioned method-related and / or apparatus-related example embodiments may include one or more of the following features: the method, functionality, operability or configuration comprises or enables: obtaining, from the responder entity, a response message to the update request message, the response property comprises one or more definitions for the preferred or required content and / or type of the response message, the response property comprises one or more conditions or thresholds relating to one or more definitions for the preferred or required content and / or type of the response message, the preferred or required content and / or type of the response message refers to one or more the following: a representation of a success of an updating operation based on the update request message when updating of the resource at the responder entity is successful, a representation of a failure of an updating operation based on the update request message when updating of the resource at the responder entity at least partially fails, a representation of the resource before an updating operation based on the update request message, the representation of a success of an updating operation comprises a representation of the entire resource after updating or a representation of an updated part of the resource after updating or a representation of the successfulness of the updating operation, the representation of a failure of an updating operation comprises a representation of a part of the resource, which failed to be updated, the indication of the response property comprises or is based on one or more attributes representing the preferred or required content and / or type of the response message, the indication of the response property is included in a body of the update request message and / or a header of or associated with the update request message, updating comprises one or more of creating the resource, creating a child of the resource, replacing the resource, modifying the resource, or partly modifying the resource, the update request message is or comprises a message based on a hypertext transfer protocol, the update request message is or comprises a PUT request message or a POST request message or a PATCH request message, the initiator entity and the responder entity are involved in or based on a service-based architecture and / or a service-based interface, the initiator entity is or comprises a service consumer or any entity configured to consume or use at least one service, the responder entity is or comprises a service producer or any entity configured to produce, expose or offer at least one service, the communication system is, comprises or relates to a 5G system. According to an example embodiment, there is provided a method of (or, stated in other words, operable or for use in / by) a responder entity of a communication system, the method comprising: obtaining, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, performing an updating operation for updating the resource based on the update request message, and generating a response message to the update request message based on the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) a responder entity of a communication system, the apparatus comprising: means for obtaining, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, means for performing an updating operation for updating the resource based on the update request message, and means for generating a response message to the update request message based on the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) a responder entity of a communication system, the apparatus comprising at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: obtain, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, perform an updating operation for updating the resource based on the update request message, and generate a response message to the update request message based on the response property. According to an example embodiment, there is provided an apparatus of (or, stated in other words, operable or for use in / by) a responder entity of a communication system, the apparatus comprising: circuitry configured to obtain, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, circuitry configured to perform an updating operation for updating the resource based on the update request message, and circuitry configured to generate a response message to the update request message based on the response property. According to various developments / modifications, any one or more of the aforementioned method-related and / or apparatus-related example embodiments may include one or more of the following features: the method, functionality, operability or configuration comprises or enables: issuing the response message, the response message is generated further based on a result of the updating operation, the response message is generated further based on the responder entity's knowledge about the initiator entity, the response property comprises one or more definitions for the preferred or required content and / or type of the response message, the response property comprises one or more conditions or thresholds relating to one or more definitions for the preferred or required content and / or type of the response message, the preferred or required content and / or type of the response message refers to one or more the following: a representation of a success of the updating operation based on the update request message when updating of the resource at the responder entity is successful, a representation of a failure of the updating operation based on the update request message when updating of the resource at the responder entity at least partially fails, a representation of the resource before the updating operation based on the update request message, the representation of a success of the updating operation comprises a representation of the entire resource after updating or a representation of an updated part of the resource after updating or a representation of the successfulness of the updating operation, the representation of a failure of the updating operation comprises a representation of a part of the resource, which failed to be updated, the indication of the response property comprises or is based on one or more attributes representing the preferred or required content and / or type of the response message, the indication of the response property is included in a body of the update request message and / or a header of or associated with the update request message, updating comprises one or more of creating the resource, creating a child of the resource, replacing the resource, modifying the resource, or partly modifying the resource, any of the update request message and the response message is or comprises a message based on a hypertext transfer protocol, the update request message is or comprises a PUT request message or a POST request message or a PATCH request message, the initiator entity and the responder entity are involved in or based on a service-based architecture and / or a service-based interface, the initiator entity is or comprises a service consumer or any entity configured to consume or use at least one service, the responder entity is or comprises a service producer or any entity configured to produce, expose or offer at least one service, the communication system is, comprises or relates to a 5G system. According to an example embodiment, there is provided a computer program product comprising (computer-executable) computer program code which, when the program code is executed (or run) on a computer or the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related example embodiments (and / or any development / modification thereof)), is configured to cause the computer to carry out the method according to the aforementioned method-related example embodiments (and / or any development / modification thereof). The computer program product may comprise or may be embodied as a (tangible / non-transitory) computer-readable (storage) medium or the like, on which the computer-executable computer program code is stored, and / or the program is directly loadable into an internal memory of the computer or a processor thereof. The term "non-transitory," as used herein, is a limitation of the medium itself (referring to e.g. a tangible medium, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM). Further developments and / or modifications of the aforementioned example embodiments are set out in the following. By way of example embodiments, a technique for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) in a communication system may be provided. Brief description of the drawings In the following, various example embodiments will be described with reference to the accompanying drawings, in which FIG. 1 shows a flowchart illustrating a method or process at / by an apparatus according to at least one example embodiment, FIG. 2 shows a flowchart illustrating a method or process at / by an apparatus according to at least one example embodiment, FIG. 3 shows a sequence diagram illustrating a procedure according to at least one example embodiment, FIG. 4 shows a sequence diagram illustrating a procedure according to at least one example embodiment, FIG. 5 shows a schematic block diagram illustrating a structure of apparatuses according to at least one example embodiment, and FIG. 6 shows a schematic block diagram illustrating a structure of apparatuses according to at least one example embodiment. Detailed description Various example embodiments are herein described with reference to particular non-limiting and illustrative examples. A person skilled in the art will appreciate that these various example embodiments are by no means limited to these non-limiting and illustrative examples, and may be more broadly applied. It is to be noted that the detailed description, at times, refers to one or more specifications being used as non-limiting and illustrative examples for certain network configurations and system deployments. More specifically, the detailed description makes reference to 3GPP standards, being used as non-limiting and illustrative examples. As such, the example embodiments provided herein can specifically employ terminology which is directly related thereto. Such terminology is only used in the context of the non-limiting and illustrative examples, and is not intended to limit the example embodiments in any way. Rather, any other system configuration or deployment may be utilized while complying with what is described herein and / or example embodiments are applicable to it. For example, various example embodiments are applicable in any (e.g., mobile / wireless) communication system, such as a 5G / NR system and a next-generation system beyond 5G. For example, various example embodiments are applicable in a 3GPP-standardized mobile / wireless communication system of Release 18 onwards. Hereinafter, various example embodiments are described using several variants and / or alternatives. It is generally to be noted that, according to certain implementations or constraints, all of the described variants and / or alternatives may be provided alone or in any conceivable combination (e.g. also including combinations of individual features of these various variants and / or alternatives). As used herein, the words "comprising" and "including" should be understood as not limiting the example embodiments to consist of only those features that have been mentioned, and example embodiments may also contain, among other things, e.g. features, structures, units, modules, or the like, that have not been specifically mentioned. As used herein, "at least one of the following: " and "at least one of " and similar wording, where the list of two or more elements are joined by "and" or "or", mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements. As used herein, according to various example embodiments, any operations of issuing or obtaining may comprise actual transmission or communication operations, i.e. sending or receiving of associated messages or signals, but may additionally or alternatively comprise related processing operations, i.e. preparing / generating associated messages or signals before sending and / or handling / processing of associated messages or signals after receiving. For example, issuing a message at / by an entity may comprise generating and / or transmitting / communicating thereof or a corresponding signal in / at / by the entity, and receiving a message at / by an entity may comprise obtaining and / or processing thereof or a corresponding signal in / at / by the entity. As used herein, a message may refer to and / or encompass any kind of corresponding information, signal or the like. In the drawings, it is to be noted that lines / arrows interconnecting individual blocks or entities are generally meant to illustrate an operational coupling there-between, which may be a physical and / or logical coupling, which on the one hand is implementation-independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional blocks or entities not shown. In flowcharts or sequence diagrams, the illustrated order of operations or actions is generally non-limiting and illustrative, and any other order of respective operations or actions is conceivable, if feasible. Herein, reference is made to a service-based architecture (SBA) in / of a 5G / NR. system for illustrative purposes. Such a service-based architecture may define, for various APIs, a service-based interface (SBI) between a consumer (which may also referred to as (NF) service consumer) and a producer (which may also referred to as (NF) service producer), over which service-related communication, in the form of (service-related) messages, is carried. Any service-based interface (SBI) used in the 5G / NR core network builds on the REST paradigm (thus providing / enabling so-called RESTful services) and makes use of HTTP methods, namely GET, POST, PUT, PATCH and DELETE, and corresponding messages. For updating a resource at a producer, a consumer sends a HTTP-based request message to the producer, namely a PUT request message (e.g. for (requesting) creating or replacing a resource) or a POST request message (e.g. for (requesting) creating a resource or a child of a resource) or a PATCH request message (e.g. for (requesting) modifying or at least partly modifying a resource). Thereupon, the producer performs a corresponding update operation on the resource (as identified in the request message), and sends a response message to the consumer. As part of the definitions of the resources used by each NF API, 5G / NR specifications define the exact data types that can be included in the response messages of these HTTP methods. That is, the possible content and / or type of response messages for updating operations performed on resources is defined in the API specifications for all SBIs, respectively. In the case of a success of the updating operation (when updating of the resource at the responder entity is successful), the content and / or type of a response message referring to a representation of a success of the updating operation may, for example, be one of the following: FULL: A representation of the entire resource after updating, in which an entire representation of the resource is returned. This has the advantage that the consumer is guaranteed to have all required information on the updating operation performed, but has the disadvantage that a high signaling load is required / caused. DELTA: A representation of an updated part of the resource after updating, in which (a representation of) the updated part, such as updated attributes, elements, or the like, is returned, i.e. a difference between the resource after updating and the resource before updating. This has the advantage that signaling load is reduced as compared with the FULL case, while it is often possible for the consumer to reconstruct a full representation of the resource, but has the disadvantage that some signaling load is still required / caused, and there is no full representation of the resource such that the consumer requires some reconstruction effort. EMPTY: A representation of the successfulness of the updating operation, in which only a success indication is returned. This has the advantage that the lowest signaling load is required / caused, while it is sometimes still possible for the consumer to reconstruct a full representation of the resource, but has the disadvantage that there is a higher risk of missing information which requires an even higher reconstruction effort. In the case of a failure of the updating operation (when updating of the resource at the responder entity at least partially), the content and / or type of a response message referring to a representation of a failure of the updating operation may, for example, be a representation of a part, such as attributes, elements, or the like, of the resource, which failed to be updated. That is, the response message may include a list of attributes, elements, or the like of the resource, that failed to be updated (which may be referred to as UpdateReport). According to current specifications, 5G / NR APIs are inconsistent and / or inflexible and / or inappropriate with regard to determination of the content and / or type of response messages for updating operations. Namely, even if a decision on content and / or type of a response message may be taken by the producer, the decision / selection logic is often pre-specified so as to be static, and the decision / selection logic is typically not based on consumer information, properties, or the like. For example, APIs can inconsistently employ the three aforementioned approaches for successful updating, often without a discernible motivation, and / or without knowing which approach will be best in practice, and / or without considering that the approach should benefit the consumer and the network resources, not just the producer. For example, APIs can be inconsistent regarding inclusion of an UpdateReport for partially successful updating. Further, decisions of the producer (which can be feasible according to certain specifications) on content and / or type of response messages can result in unnecessary network load and increased difficulty of the consumer's logic implementation. Accordingly, there are issues, problems and / or drawbacks in terms of handling of a resource update request from an initiator entity to a responder entity and a related response message from the responder entity to the initiator entity, e.g. regarding consistency, flexibility and / or appropriateness. Therefore, a technique for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) in a communication system may be advantageous. According to various example embodiments, there are provided measures / mechanisms for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) in a communication system. For example, various example embodiments provide measures / mechanisms for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) between an initiator entity, such as e.g. a (NF) service consumer, and a responder entity, such as a (NF) service producer, in a communication system. Hence, various example embodiments are applicable in / for but not limited to service-based interfaces (SBI), or APIs, used in a 5G / NR core network and / or services, such as RESTful services. FIG. 1 shows a flowchart illustrating a method or process at / by an apparatus according to at least one example embodiment. In this regard, the apparatus is or, stated in other words, the method or process is a method or process of (or, stated in other words, operable or for use in / by) an initiator entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, and the referenced responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, without being limited accordingly. As shown in FIG. 1, the method or process comprises an operation (S110) of specifying a response property as a preferred or required (or expected) content and / or type of a response message to an update request message, and an operation (S120) of issuing, e.g. for or, stated in other words, directed or addressed to a responder entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of the response property. The update request message or, more specifically, the indication of the response property included therein can (be configured to) instruct or cause the responder entity to take into consideration the specified response property in generating (and issuing) a response message to the update request message. As illustrated by a dashed-line block, the method or process may comprises an operation (S130) of obtaining, from the responder entity, a response message to the update request message. The response message may have a content and / or type according to the specified response property. According to an example embodiment, response property, i.e. the preferred or required (or expected) content and / or type of a response message, may refer to a representation of or regarding the resource to be updated and / or a representation of or regarding an update operation on the resource to be updated. According to an example embodiment, the specifying of the response property may be based on one or more parameters, criteria, conditions, or the like. For example, the initiator entity may specify the response property in view of one or more of the following: processing power and / or implementation complexity to extract information (e.g. information required for further processing, such as e.g. information for reconstructing necessary information) from the response message (compared to looking it up in its cache); network / interface load or traffic; (existence or availability or load of) internal logic for retrieving, reconstructing and / or checking contents of entries (of the resource) requested to be updated and / or performing actions based on them. Hence, the initiator entity may (make an educated decision to) specify, for example, a preference or requirement (or expectation) for getting a response message with FULL or DELTA or EMPTY type or content (as described above) and / or an Update Report (as described above) depending on its local information / knowledge. FIG. 2 shows a flowchart illustrating a method or process at / by an apparatus according to at least one example embodiment. In this regard, the apparatus is or, stated in other words, the method or process is a method or process of (or, stated in other words, operable or for use in / by) a responder entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, and the referenced initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, without being limited accordingly. As shown in FIG. 2, the method or process comprises an operation (S210) of obtaining, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required (or expected) content and / or type of a response message to the update request message, an operation (S220) of performing an updating operation for updating the resource based on the update request message, and an operation (S230) of generating a response message to the update request message based on the response property. The update request message or, more specifically, the indication of the response property included therein can (be configured to) instruct or cause the responder entity to take into consideration the specified response property in generating (and issuing) a response message to the update request message. As illustrated by a dashed-line block, the method or process may comprises an operation (S240) of issuing, e.g. for or, stated in other words, directed or addressed to the initiator entity, the response message. The response message may have a content and / or type according to the response property. According to an example embodiment, response property, i.e. the preferred or required (or expected) content and / or type of a response message, may refer to a representation of or regarding the resource to be updated and / or a representation of or regarding an update operation on the resource to be updated. As used herein, content and type of a response message may be different or corresponding characteristics thereof. For example, a specific type may imply or correspond to a specific content, or vice versa, but some specific type may relate to a predefined message type or code, irrespective of its contents. For example, 200 or 200 OK or 204 No Content may be regarded as specific message type, 200 (full / delta) or 200 OK (full / delta) or 204 No Content (empty) may be regarded as message type and / or specific message content. An UpdateReport in any one of these messages may be regarded as specific message content. According to various example embodiments, the response property may comprise one or more definitions (or instances) for the preferred or required (or expected) content and / or type of the response message. Namely, more inputs (than a single input) can be specified / defined and provided to the responder entity by the initiator entity. For example, the initiator entity may specify, as the preferred or required (or expected) content and / or type of a response message, a message type such as 200 (delta) or 200 OK (delta), and a message content such as UpdateReport. According to various example embodiments, the response property may comprise one or more conditions or thresholds relating to one or more definitions (or instances) for the preferred or required (or expected) content and / or type of the response message. For example, the initiator entity may specify / define multiple inputs as preferences, each linked to one or more conditions or thresholds such as e.g. the following: The use of FULL (as described above) is requested if the resource size is less than X MB, otherwise the use of DELTA (as described above) is requested. A representation of the old resource (before the update) is requested in the case of a specific kind / type of update method or update request message, such as PUT method or request message. According to various example embodiments, the preferred or required (or expected) content and / or type of the response message may refer to one or more the following: (i) a representation of a success of an updating operation based on the update request message when updating of the resource at the responder entity is successful, (ii) a representation of a failure of an updating operation based on the update request message when updating of the resource at the responder entity at least partially fails, (iii) a representation of the resource before an updating operation based on the update request message. In case of (i) the representation of a success of an updating operation may comprise a representation of the entire resource after updating (corresponding to FULL, as described above) or a representation of an updated part of the resource after updating (corresponding to DELTA, as described above) or a representation of the successfulness of the updating operation (corresponding to EMPTY, as described above). In case of (ii) the representation of a failure of an updating operation may comprise a representation of a part of the resource, which failed to be updated (corresponding to Update Report, as described above). Accordingly, the response message may be (generated) based on a result of the updating operation at / by the responder entity. For example, in case of a partially unsuccessful update, an UpdateReport may be included in the response message, depending on the response property (and optionally depending on related condition / s and / or threshold / s). According to various example embodiments, the indication of the response property may comprise or be based on one or more attributes representing the preferred or required (or expected) content and / or type of the response message, and / or the indication of the response property may be included in a body of the update request message and / or a header of or associated with the update request message. For example, one or more of the following attributes (or the like) may be defined as / in (the indication of) the response property by the initiator entity: Attribute name Data type P Cardi nality Description prefResp UpdateRespon seType 0 0..1 Indicates a preference or request (or expectation) for the contents of the response. (UpdateResponseType is an enum with possible values FULL, DELTA, EMPTY, which may also be extended if needed.) reportlnd boolean 0 0..1 If true, a report of the failed attributes in case of partial success is requested. Such attribute / s may be included in / to the data type(s) used in the body of the update request message and / or a header thereof. For example, a specific header with such attribute / s may be used, e.g. a generic 3GPP SBI header can be defined with equivalent possible values. Accordingly, the initiator entity may construct, build, etc. the body and / or related header of the update request message based on the response property, e.g. by including corresponding one or more attributes. The responder entity may retrieve, reconstruct, check, etc. the response property, g. by corresponding one or more attributes, in / from the update request message. According to various example embodiments, updating of a resource may comprises one or more of creating the resource, creating a child of the resource, replacing the resource, modifying the resource, or partly modifying the resource. According to various example embodiments, updating of a resource may and / or the response message may be or comprise a message based on a hypertext transfer protocol (HTTP), e.g. HTTP / 2). According to various example embodiments, the update request message may be or comprise a HTTP-based request message, such as a PUT request message or a POST request message or a PATCH request message. For example, a PUT request message may be used for (requesting) creating or replacing a resource, a POST request message may be used for (requesting) creating a resource or a child of a resource, a PATCH request message may be used for (requesting) modifying or at least partly modifying a resource, or the like. FIG. 3 shows a sequence diagram illustrating a procedure according to at least one example embodiment. As shown in FIG. 3, an initiator entity, such as e.g. a (NF service) consumer, issues / sends an update request message to request updating of a resource at a responder entity, said update request message including an indication of a response property as a preferred or required (or expected) content and / or type of a response message to the update request message. Upon obtaining / receiving the update request message, a responder entity, such as e.g. a (NF service) producer, issues / sends a response message to the update request message based on the response property or, stated in other words, in accordance with the preferred or required (or expected) content and / or type of the response message. FIG. 4 shows a sequence diagram illustrating a procedure according to at least one example embodiment. As shown in FIG. 4, a NF service consumer issues / sends a PUT or PATCH request message as an update request message, including an identification of the resource to be updated, as / by resourceUri, and an indication of the response property, as / by prefResp=X (specifying that X={FULL, DELTA, EMPTY} is preferred as update response type) and reportInd=Y (specifying that Y={TRUE, FALSE} is preferred for inclusion of UpdateReport, if the requested update partially fails). Upon obtaining / receiving this PUT or PATCH request message, a NF service producer decides / selects an appropriate response, in terms of type and / or content, based on the included indication of the response property, optionally also considering additional information / knowledge about the NF service consumer, which is available at the NF service producer. Based on the decision / selection, the NF service producer generates a corresponding response message and issued / sends the thus generated response message to the NF service consumer. As is illustrated, the response may be 200 OK (full), i.e. a response of type 200 OK (full), which may also be regarded as a response having a corresponding content, i.e. a full representation of the entire resource, or 200 OK (delta), i.e. a response of type 200 OK (delta), which may also be regarded as a response having a corresponding content, i.e. a representation of an updated part of the resource, or 204 No Content (empty), i.e. a response of type 204 No Content (empty), which may also be regarded as a response having a corresponding content, i.e. a representation of the successfulness of the updating operation but no representation of the resource as such. In any one of these responses, an UpdateReport may be included in case of (partial) failure of the updating operation. A similar procedure, as described above for / with a PUT or PATCH request message, may be applied for a POST request message. For example, for / with a POST request message, a specification and thus a decision / selection may be applied for FULL and EMPTY. For example, for / with a POST request message, a specification and thus a decision / selection may be applied for DELTA, at least if it is defined that this requests inclusion of a delta or difference in comparison the representation of the resource sent in the request, rather than in comparison to a previous representation of the resource (which does not exist in the case of POST), in the response message. As described above, example embodiments are applicable to any API, such as e.g. any service-based interface (SBI) between (an entity serving or acting as) a consumer (which may also referred to as (NF) service consumer) and (an entity serving or acting as) a producer (which may also referred to as (NF) service producer). In the following, a use case of example embodiments is explained in more detail for illustrative purposes. This use case relates to an UDR API, more specifically the Nudr_DataRepository API for Policy Data. There are UDR APIs for policy, application and exposure data in the UDR, which specify / define two possible responses for a request that updates a resource, i.e. an update request message. For example, the PATCH operation / method for modifying a BDT data resource (which may be briefly referred to as PATCH for Background Data) specifies / defines 200 containing a full representation of the updated resource or 204 with no content as two possible responses, as is derivable from Table 5.2.9.3.4-3 of 3GPP TS29.519 V18.0.0. However, the choice of the response to be used, i.e. the choice between 200 and 204, is left to the UDR implementation, i.e. the NF service producer, and it is unclear what logic the UDR, i.e. the NF service producer, could usefully employ to make a decision. This can lead to sub-optimal handling and unnecessarily big response sizes. Similar concerns can apply to certain PUT and / or POST operations / methods. If an update request (e.g. PATCH or PUT) leads the NF service producer to update also attributes of the resource other than those that were indicated in the request (which is a very rare case for the UDR, if possible at all), then it is meaningful that the NF service producer return 200 with the full representation of the resource. However, if only the attributes included in the request are updated, then the NF service producer can arbitrarily return 200 with the full representation of the resource or 204 with no content, as criteria for an educated decision lie on the NF service consumer side and the UDR has no clue if a 200 response with a full representation of the resource would bring any benefit or simply create unnecessary signaling compared to a 204 response. The NF service consumer could prefer (or require) a 200 response with a full representation because e.g.: a) it saves processing power and implementation complexity to extract information from the response compared to looking it up in its cache; b) it has internal logic for checking the contents of entries that it updates and performing actions based on them, but it does not store data locally (e.g., an AF may do a PATCH to change the "bdtpStatus" of a BDT and require to see the rest of the attributes that are currently stored in the UDR for this BDT in order to determine further BDT planning actions, wherein in that case a 204 response to the PATCH would mean that the AF would do another GET to retrieve the BDT data, which is unnecessary signalling). In all other cases, a 204 response with no content would be preferable for the network and for the NF service producer, which would not have to construct and return a full representation of the resource. Based on the above, for cases where two or more responses, e.g. both 200 and 204, are specified / defined as possible responses without a deterministic way to select one of them by / at the NF service producer, it is beneficial in terms of system performance if the NF service consumer can indicate the preferred (or required or expected) response, i.e. the type and / or content of a response to an update request. Therefore, example embodiments propose / teach to implement a consumer indication in an update request such that the producer can make a proper (and deterministic) decision on the response to be sent, i.e. the producer can generate (and issue) a response with appropriate type and / or content. To this end, the following specifications / definitions can be provided in 3GPP TS29.519 V18.0.0 for the use case of PATCH for Background Data (for the Nudr_DataRepository API). The data type "BdtDataPatch", i.e. the data structure supported by the PATCH request body, can be specified / defined (in section 5.4.2.27) by including an attribute which may e.g. be called fullResInd, e.g. as follows. Attribute name Data type iiiii Cardi nality Description bdtpStatus BdtPolicyStatus 0 0..1 Contains the validation status for a negotiated BDT policy. It shall be included when the BDT policy is renegotiated. transPolicy TransferPolicy 0 0..1 This IE contains the transfer policy. fullResInd boolean 0 0..1 Indicates if the NF service consumer expects or prefers a response containing a full representation of the resource upon successful execution of the request. If set to true, then the NF service consumer prefers a full representation. Default is false. Accordingly, an Open API file for Nudr_Data Repository API for Policy Data, as defined / specified in Annex A.2, can contain e.g. the following code for fullResInd: BdtDataPatch: description: Contains the modified background data transfer data. type: object properties : transPolicy: $ref: 'TS29554_Npcf_BDTPolicyControl.yaml# / components / schemas / Tra nsferPolicy’ bdtpStatus: $ref: '# / components / schemas / BdtPolicyStatus' fullResInd: type: boolean description: > Indicates if the NF service consumer expects or prefers a response containing a full representation of the resource upon successful execution of the request. The data structures supported by the PATCH request body can be specified / defined (in section 5.2.9.3.4) by including NOTE 2, e.g. as follows: Data type llillll Cardi nality Response codes Description BdtData M 1 200 OK The resource has been successfully updated and a response body containing BDT data shall be returned. (NOTE 2) n / a 204 No Content Successful case. The resource has been successfully updated and no additional content is to be sent in the response message. (NOTE 2) NOTE1: T listed ir NOTE 2: Ir conten of the c he mandatory i table 5.2.7.1-order to deter t, the NF servic attribute "fulIRe HTTP error status codes for the PATCH method 1 of 3GPP TS 29.500 [4] also apply. mine if it will respond with 200 OK or 204 No ;e producer may take into consideration the value slnd" in the request. As explained above, it is beneficial for system performance to allow the NF service consumer to provide an indication of preferred / expected (or required) response (200 with full resource representation vs 204 with no content) in cases where both 200 and 204 are currently specified / defined as possible responses without a deterministic way to select one of them (such as in section 5.2.9.3.4 of 3GPP TS29.519 V18.0.0). To this end, a boolean indication about if a full resource representation is expected can be added in inputs of the BdtData PATCH request. Thereby, suboptimal protocol performance and unnecessary signaling can be avoided or at least mitigated. As described above, various example embodiments provide a technique for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) in a communication system. For example, various example embodiments provide measures / mechanisms for (e.g. enabling / realizing) dynamic control of a property of a response (message) to an update request (message) between an initiator entity, such as e.g. a (NF) service consumer, and a responder entity, such as a (NF) service producer, in a communication system. Hence, various example embodiments are applicable in / for but not limited to service-based interfaces (SBI), or APIs, e.g. used in a 5G / NR core network and / or services, such as RESTful services. In a technique according to various example embodiments, an initiator entity such as a consumer is provided with the possibility of indicating requirement / s and / or preference / s (and / or expectation / s) on the type and / or content of a response to an update request from a responder entity such as a producer. In this regard, an initiator entity such as a consumer may be enabled to send an update request to dynamically indicate its requirement / s and / or preference / s (and / or expectation / s) on the type and / or content of a response to an update request from a responder entity such as a producer. By virtue of various embodiments, consistent and appropriate determination of the content and / or type of response messages for updating operations at a responder entity is enabled, while being flexible in view of preferences and / or requirements (and / or expectations) of an initiator entity. By virtue of various embodiments, an efficient (or improved) protocol performance and / or signaling (load / traffic) may be achieved. According to current specifications, 5G / NR APIs are inconsistent and / or inflexible and / or inappropriate with regard to determination of the content and / or type of response messages for updating operations. Namely, even if a decision on content and / or type of a response message may be taken by the producer, the decision / selection logic is often pre-specified so as to be static, and the decision / selection logic is typically not based on consumer information, properties, or the like. The above-described functionality as well as its related operations, procedures, methods and processes may be implemented by respective functional elements, entities, modules, units, processors, or the like, as described below. These functional elements, entities, modules, units, processors, or the like, i.e. the implementation of one or more example embodiments, may be realized in a cloud environment, by SDN, by NFV / NFVI, or the like. While various example embodiments are described with reference to operations, procedures, methods and processes, these example embodiments also cover respective apparatuses, entities, modules, units, network nodes and / or systems, including software and / or hardware thereof. Respective example embodiments are described below referring to FIGS. 5 and 6, while for the sake of brevity reference is made to the detailed description of respective corresponding configurations / setups, schemes, processes, sequences, methods as well as functionalities, principles and operations according to FIGS. 1 to 4. In FIGS. 5 and 6, the blocks are basically configured to perform respective methods, procedures and / or functions as described above. The entirety of blocks are basically configured to perform the methods, procedures and / or functions as described above, respectively. With respect to FIGS. 5 and 6, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation-independent, i.e. may be implemented by means of any kind of hardware or software or combination thereof, respectively. Further, in FIGS. 5 and 6, only those functional blocks are illustrated, which relate to any one of the above-described methods, procedures and / or functions. A skilled person will acknowledge the presence of any other conventional functional blocks required for an operation of respective structural arrangements, such as e.g. a power supply, a central processing unit, respective memories or the like. Among others, one or more memories are provided for storing programs or program instructions for controlling or enabling the individual functional entities or any combination thereof to operate as described herein in relation to example embodiments. FIG. 5 shows a schematic diagram illustrating a structure of apparatuses according to at least one example embodiment. Herein, an apparatus can represent a physical entity or component, e.g. a structural device implementing a specific network element, entity or function or the functionality thereof as such, or a functional or logical entity or component. For example, the illustrated apparatus may be realized in or by a server or the like in a cloud environment, e.g. by a cloud-based implementation. As indicated in FIG. 5, according to at least one example embodiment, an apparatus 500 may comprise or realize at least one processor 510 and at least one memory 520 (and possibly also at least one interface 530), which may be operationally connected or coupled, for example by a bus 540 or the like, respectively. The processor 510 and / or the interface 530 of the apparatus 500 may also include a modem or the like to facilitate communication over a (hardwire or wireless) link, respectively. The interface 530 of the apparatus 500 may include a transmitter, receiver or transceiver connected or coupled to one or more antennas, antenna units, such as antenna arrays or communication facilities or means for (hardwire or wireless) communications with the linked, coupled or connected device(s), respectively. The interface 530 of the apparatus 500 is generally configured to communicate with at least one other apparatus, device, node or entity (in particular, the interface thereof). The memory 520 of the apparatus 500 may represent a (non-transitory / tangible) storage medium (e.g. RAM, ROM, EPROM, EEPROM, etc.) and store respective software, programs, program products, macros or applets, etc. or parts of them, which may be assumed to comprise program instructions or computer program code that, when executed by the respective processor, enables the respective electronic device or apparatus to operate in accordance with example embodiments described herein. Further, the memory 520 of the apparatus 500 may (comprise a database to) store any data, information, or the like, which is used in the operation of the apparatus. According to various example embodiments, respective apparatuses (and / or parts thereof) may represent means for performing respective operations and / or exhibiting respective functionalities, and / or the respective devices (and / or parts thereof) may have functions for performing respective operations and / or exhibiting respective functionalities. In view of the above, the illustrated apparatus 500 can be used in practicing one or more of the example embodiments, as described herein. When in the subsequent description it is stated that the processor (or some other means) is configured to perform some function, this is to be construed to be equivalent or corresponding to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with a computer program code stored in the memory of the respective apparatus or otherwise available (it should be appreciated that the memory may also be an external memory or provided / realized by a cloud service or the like), is configured to cause the apparatus to perform at least the thus mentioned function. It should be appreciated that herein processors, or more generally processing portions, should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors. According to at least one example embodiment, the illustrated apparatus 500 may represent or realize / embody a (part of a) initiator entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, and the referenced responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, without being limited accordingly. Hence, the apparatus 500 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described (for an initiator entity or a (NF) service consumer or consumer) in any one of FIGS. 1, 3 and 4. Accordingly, the apparatus 500 may be caused or the apparatus 500 or its at least one processor 510 (possibly together with computer program code stored in its at least one memory 520) may be configured to specify a response property as a preferred or required content and / or type of a response message to an update request message, and to issue, e.g. for a responder entity, an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. Further, the apparatus 500 may be caused or the apparatus 500 or its at least one processor 510 (possibly together with computer program code stored in its at least one memory 520) may be configured to obtain, e.g. from the responder entity, a response message to the update request message According to at least one example embodiment, the illustrated apparatus 500 may represent or realize / embody a (part of a) responder entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, and the referenced initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, without being limited accordingly. Hence, the apparatus 500 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described (for a responder entity or (NF) service producer or producer) in any one of Figures 2, 3 and 4. Accordingly, the apparatus 500 may be caused or the apparatus 500 or its at least one processor 510 (possibly together with computer program code stored in its at least one memory 520) may be configured to obtain, e.g. from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, to perform an updating operation for updating the resource based on the update request message, and to generate a response message to the update request message based on the response property. Further, the apparatus 500 may be caused or the apparatus 500 or its at least one processor 510 (possibly together with computer program code stored in its at least one memory 520) may be configured to issuing, e.g. for the initiator entity, the response message. As mentioned above, an apparatus according to at least one example embodiment may be structured by comprising respective one or more units or means or circuitries for performing corresponding operations, procedures and / or functions. For example, such one or more units or means or circuitries may be implemented / realized on the basis of an apparatus structure, as illustrated in FIG. 5, e.g. by one or more processors 510, one or more memories 520, one or more interfaces 530, or any combination thereof. FIG. 6 shows a schematic diagram illustrating a structure of apparatuses according to at least one example embodiment. As shown in FIG. 6, an apparatus 610 according to at least one example embodiment may represent or realize / embody a (part of a) initiator entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, and the referenced responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, without being limited accordingly. Hence, the apparatus 610 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described (for an initiator entity or a (NF) service consumer or consumer) in any one of FIGS. 1, 3 and 4. The apparatus 610 may comprise (at least) one or more unit / means / circuitry, denoted by specifying section 611, which represents any implementation for (or configured to) specifying (specify) a response property as a preferred or required content and / or type of a response message to an update request message, and one or more unit / means / circuitry, denoted by issuing section 612, which represents any implementation for (or configured to) issuing (issue), e.g. for the responder entity, an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. Further, the apparatus 610 may comprise (at least) one or more unit / means / circuitry, denoted by obtaining section 613, which represents any implementation for (or configured to) obtaining (obtain), e.g. from the responder entity, a response message to the update request message. As shown in FIG. 6, an apparatus 620 according to at least one example embodiment may represent or realize / embody a (part of a) responder entity, or an element, function or entity of similar / comparable functionality or operability, in / of a (mobile / wireless) communication system. In the context of SBI / SBA, such responder entity may for example be or relate to a (NF) service producer or any entity configured to produce, expose or offer at least one service, and the referenced initiator entity may for example be or relate to a (NF) service consumer or any entity configured to consume or use at least one service, without being limited accordingly. Hence, the apparatus 620 may be configured to perform a procedure and / or exhibit a functionality and / or implement a mechanism, as described (for a responder entity or (NF) service producer or producer) in any one of Figures 2, 3 and 4. The apparatus 620 may comprise (at least) one or more unit / means / circuitry, denoted by obtaining section 621, which represent any implementation for (or configured to) obtaining (obtain), e.g. from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content and / or type of a response message to the update request message, one or more unit / means / circuitry, denoted by updating section 622, which represent any implementation for (or configured to) performing (perform), an updating operation for updating the resource based on the update request message, and one or more unit / means / circuitry, denoted by generating section 623, which represent any implementation for (or configured to) generating (generate), a response message to the update request message based on the response property. Further, the apparatus 620 may comprise (at least) one or more unit / means / circuitry, denoted by issuing section 624, which represent any implementation for (or configured to) issuing (issue), e.g. for the initiator entity, the response message. For further details regarding the operability / functionality of the apparatuses (or units / means thereof) according to example embodiments, reference is made to the above description in connection with any one of FIGS. 1 to 4, respectively. According to various example embodiment, the various functionalities, operations, sections, units, means, circuitries, or the like may be implemented (or integrated) in one or more apparatuses or systems, and / or may be distributed over one or more apparatuses or systems. Accordingly, depending one needs, constraints, specifications, realizations, or the like, at least one apparatus and / or at least one system may be provided according to various example embodiment, which includes one or more or even all of the above-described functionalities, operations, sections, units, means, circuitries, or the like. According to example embodiments, any one of the (at least one) processor, the (at least one) memory and the (at least one) interface, as well as any one of the illustrated units / means, may be implemented as individual modules, chips, chipsets, circuitries or the like, or one or more of them can be implemented as a common module, chip, chipset, circuitry or the like, respectively. As used herein, the term "circuitry" may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions), and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device. According to example embodiments, a system may comprise any conceivable combination of any depicted or described apparatuses and other network elements or functional entities, which are configured to cooperate as described above. In general, it is to be noted that respective functional blocks or elements according to various embodiments described herein can be implemented by any known means, either in hardware and / or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device. Generally, a basic system architecture of a (tele)communication network including a mobile communication system where some examples of example embodiments are applicable may include an architecture of one or more communication networks including wireless access network sub- / system(s) and possibly core network(s). Such an architecture may include one or more communication network control elements or functions, such as e.g. access network elements, radio access network elements, access service network gateways or base transceiver stations, like a base station, an access point, a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit, which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements or functions, like user devices or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, core network elements or network functions, such as gateway network elements / functions, mobility management entities, a mobile switching center, servers, databases and the like may be included. The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. It should be appreciated that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below. A communication network architecture as being considered in examples of example embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet, including the Internet-of-Things. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the (tele)communication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network etc., and / or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. a cloud infrastructure. Any method step is suitable to be implemented as software or by hardware without changing the idea or scope of the various example embodiments. Such software may be software code independent and can be specified using any known or future developed programming language, such as e.g. Java, C++, C, and Assembler, as long as the functionality defined by the method steps is preserved. Such hardware may be hardware type independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components. A device / apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device / apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution / being run on a processor. A device may be regarded as a device / apparatus or as an assembly of more than one device / apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example. Apparatuses and / or units / means or parts thereof can be implemented as individual devices, but this does not exclude that they may be implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person. Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means / portions or embodied in a signal or in a chip, potentially during processing thereof. Various example embodiments also cover any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable. In view of the above, there are provided measures for (enabling / realizing) dynamic control of a property of a response (message) to an update request (message) in a communication system. Such measures may exemplarily comprise that an initiator entity specifies a response property as a preferred or required content and / or type of a response message to an update request message, and issues an update request message to request updating of a resource at a responder entity, said update request message including an indication of the response property. Such measures may exemplarily further comprise that the responder entity obtains, from the initiator entity, the update request message including the indication of the response property, and generates a response message to the update request message based on the response property. Even though various example embodiments are described above with reference to the accompanying drawings, it is to be understood that the various example embodiments are not restricted thereto. Rather, it is apparent to those skilled in the art that the various example embodiments can be modified in many ways without departing from the intended scope. List of acronyms and abbreviations 3GPP 3rd Generation Partnership Project 5G Fifth Generation AF Application Function API Application Programming Interface BDT Background Data Transfer HTTP HyperText Transfer Protocol NF Network Function NFV Network Functions Virtualisation NFVI Network Functions Virtualisation Infrastructure NR New Radio REST Representational State Transfer SBA / SBI SDN Service-Based Architecture / Interface Software-Defined Networking UDR Unified Data Repository

Claims

1. A method of a responder entity of a communication system, the method comprising:obtaining, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content of a response message to the update request message,performing an updating operation for updating the resource based on the update request message,generating a response message to the update request message based on the response property, andissuing the response message to the initiator entity.

2. The method according to claim 1, whereinthe response message is generated further based on a result of the updating operation.

3. The method according to claim 1 or 2, wherein the preferred or required content of the response message refers to one of the following:- a representation of success of the updating operation based on the update request message when updating of the resource at the responder entity is successful, wherein the representation of success of the updating operation comprises a representation of the entire resource after updating or a representation of an updated part of the resource after updating or a representation of the successfulness of the updating operation;- a representation of failure of the updating operation based on the update request message when updating of the resource at the responder entity at least partially fails, wherein the representation of failure of the updating operation comprises a representation of a part of the resource which failed to be updated.

4. The method according to any one of claims 1 to 3, wherein- the indication of the response property comprises one or more attributes representing the preferred or required content of the response message, or- the indication of the response property is included in a body of the Ut-A ZA "A 4” ZA |ZAZ",4_ “1 / 1 ZAP” *A La ZA «A ZA ZA P” ZA 4“ 4" kA ZA ■ I PA ZA *A 4” ZA k"ZA ZA I i ZA Z* 4“ PAA ZA Z* Z* "A ZA ZApoate request message or a neauer or tne upoate request message.

5. The method according to any one of claims 1 to 4, whereinany of the update request message and the response message is a message based on a hypertext transfer protocol, andthe update request message is a PUT request message or a POST request message or a PATCH request message.

6. The method according to any one of claims 1 to 5, whereinthe initiator entity and the responder entity are based on a servicebased architecture, andthe initiator entity is a service consumer, andthe responder entity is a service producer.

7. An apparatus of a responder entity of a communication system, the apparatus comprising:means for obtaining, from an initiator entity, an update request message to request updating of a resource at the responder entity, said update request message including an indication of a response property as a preferred or required content of a response message to the update request message,means for performing an updating operation for updating the resource based on the update request message,means for generating a response message to the update request message based on the response property, andmeans for issuing the response message to the initiator entity.the response message is generated further based on a result of the updating operation.

9. The apparatus according to claim 7 or 8, wherein the preferred or required content of the response message refers to one of the following:- a representation of success of the updating operation based on the update request message when updating of the resource at the responder entity is successful, wherein the representation of success of the updating operation comprises a representation of the entire resource after updating or a representation of an updated part of the resource after updating or a representation of the successfulness of the updating operation;- a representation of failure of the updating operation based on the update request message when updating of the resource at the responder entity at least partially fails, wherein the representation of failure of the updating operation comprises a representation of a part of the resource which failed to be updated.

10. The apparatus according to any one of claims 7 to 9, wherein- the indication of the response property comprises one or more attributes representing the preferred or required content of the response message, orthe indication of the response property is included in a body of the update request message or a header of the update request message.

11. The apparatus according to any one of claims 7 to 10, whereinany of the update request message and the response message is a message based on a hypertext transfer protocol, andthe update request message is a PUT request message or a POST request message or a PATCH request message.

12. The apparatus according to any one of claims 7 to 11, whereinthe initiator entity and the responder entity are based on a servicebased architecture, andthe initiator entity is a service consumer, and the responder entity is a service producer.

13. A computer program product comprising computer program code which, 5 when the computer program code is executed on a computer, is configured to cause the computer to carry out the method according to any one of claims 1 to 6.

Images