Perception method, communication device and system

Abstract

The invention provides a sensing method, a communication device and a system. In the method, after receiving a perception request, a network element responsible for a perception management function, such as an SF or a perception server, acquires a target service requirement according to the perception request, the target service requirement is used for determining a KPI for perceiving a terminal, and the determination of the target service requirement is related to the perception authority of the terminal. The SF or the sensing server can also confirm whether to agree to adopt the target service requirement to an external server (such as an AS or an AF) when the target service requirement is different from the service requirement carried in the sensing request, and then initiates a sensing process to the terminal based on the target service requirement under the condition of agreement. According to the method, the target service requirement is acquired in combination with the sensing permission of the terminal, so that the sensing request message can be flexibly responded according to the security requirement of the terminal equipment, and the security requirements of different terminal equipment are met.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular, to a sensing method, a communication device, and a system. Background Art

[0002] In a mobile communication network, some base stations or terminals in a radio access network (RAN) can be used as sensing nodes due to their sensing capabilities brought by electromagnetic waves. The implementation of sensing is similar to the principle of a radar. That is, a transmitter emits electromagnetic waves, and after the electromagnetic waves are reflected by an object to be sensed, they are acquired by a receiver. The receiver can further process the acquired reflected signal (which can be called sensing raw data) to obtain sensing data, and this sensing data can be used to obtain a sensing result. The above-mentioned transmitter and receiver can both be called sensing nodes.

[0003] In the current sensing process, an application function (AF) network element or an application server (AS) of a sensing application can send a sensing request to a network exposure function (NEF) network element to request sensing of a specific terminal. The AF, AS, or terminal can also directly send a sensing request to a network element responsible for the sensing function in the communication network. In response to this sensing request, the network element responsible for the sensing function in the communication network can initiate a sensing process for the specific terminal.

[0004] Currently, there is no relevant secure process for the sensing process of a specific terminal. Summary of the Invention

[0005] This application provides a sensing method, a communication device, and a system, so as to flexibly respond to a sensing request message according to the security requirements of a terminal device and meet the security requirements of different terminal devices.

[0006] In a first aspect, a sensing method is provided. This method can be applied to a second communication device, which can be, for example, a sensing function (SF) network element or a sensing server, or a component configured in the SF network element or the sensing server, such as a processor, a chip, a chip system, etc., or a logical module or software capable of implementing all or part of the functions of the second communication device. This application does not make any limitations in this regard.

[0007] The method includes: receiving a sensing request for requesting to sense a terminal; obtaining a target service requirement for determining key performance indicators (KPIs) for sensing the terminal, where the target service requirement is related to the sensing permission of the terminal, and the sensing permission is used to determine whether the terminal is allowed or not allowed to be sensed.

[0008] The sensing request may be, for example, a sensing request from a first communication device (such as an AF network element or an AS), and can be used to request to sense one or more terminals. For the convenience of understanding and description in this article, the method provided in this application is described by taking the request to sense one terminal as an example. The terminal may be any terminal requested to be sensed.

[0009] In the solution provided in this application, the target service requirement for determining the KPIs for sensing the terminal is related to the sensing permission of the terminal, so that the sensing process initiated for the terminal is adapted to the sensing permission of the terminal, rather than blindly directly determining the KPIs for sensing the terminal according to the service requirements requested by the AF network element or the AS, etc. Or rather, this application can obtain the target service requirement in terms of the terminal granularity. Specifically, the target service requirements of different terminals can be determined according to their respective corresponding sensing permissions. Therefore, considering the security requirements of different terminals, the target service requirements of different terminals are flexibly obtained according to the sensing permissions of different terminals, and then the sensing process is initiated for different terminals based on different KPIs, rather than blindly using the same KPIs to sense all terminals requested to be sensed according to the service requirements requested by the AF network element or the AS.

[0010] Optionally, the sensing permission of the terminal includes: the sensing permission subscribed by the terminal, the sensing notification feedback of the terminal, or the result of whether the terminal is allowed to be sensed determined by the sensing permission subscribed by the terminal and the sensing notification feedback of the terminal.

[0011] The sensing permission subscribed by the terminal or the sensing permission fed back by the terminal can indicate whether the terminal is allowed or not allowed to be sensed, and can also be used in combination to determine whether the terminal is allowed or not allowed to be sensed.

[0012] Among them, the sensing permission subscribed by the terminal is the sensing permission subscribed by the terminal with the network operator, and can also be called the configured sensing permission, or the default sensing permission, or the sensing permission stored on the network side. For example, the terminal can clarify whether it is allowed to be sensed by subscribing with the operator.

[0013] Exemplarily, the sensing permission subscribed by the terminal includes one or more of the following: not allowed to be sensed, allowed to be sensed, or allowed to be sensed and need to notify the terminal (but no reply from the terminal) etc.

[0014] It is not difficult to see that the sensing permission subscribed by the terminal can indicate whether the terminal allows or does not allow to be sensed.

[0015] The sensing notification feedback of the terminal is used to indicate the response of the terminal to the received sensing notification request, and can be used to indicate whether the terminal agrees or disagrees to be sensed, and thus can be used to determine whether the terminal allows or does not allow to be sensed. Therefore, it can also be called the sensing permission feedback by the terminal. For example, the second communication device that receives the sensing request can send a sensing notification request to the terminal, and this sensing notification request can be used to request the terminal to reply whether it agrees to be sensed.

[0016] In some cases, simply based on the sensing permission subscribed by the terminal or the sensing notification feedback of the terminal, it may not be possible to determine whether the terminal allows to be sensed, and it is necessary to combine the two to determine.

[0017] Exemplarily, the sensing permission subscribed by the terminal is: it is necessary to notify the terminal that it is allowed to be sensed when the terminal replies agree or does not reply, or, it is necessary to notify the terminal that it is allowed to be sensed only when the terminal replies agree.

[0018] Among them, "it is necessary to notify the terminal that it is allowed to be sensed when the terminal replies agree or does not reply" specifically means: it is necessary to notify the terminal that it is allowed to be sensed when the terminal replies agree or does not reply, and it is not allowed to be sensed when the terminal replies disagree; "it is necessary to notify the terminal that it is allowed to be sensed only when the terminal replies agree" specifically means: it is necessary to notify the terminal that it is allowed to be sensed when the terminal replies agree, and it is not allowed to be sensed when the terminal replies disagree or does not reply.

[0019] Whether the terminal allows to be sensed can be determined according to whether the terminal makes a reply or the content of the reply to the received sensing notification request. For example, the second communication device that receives the sensing request can send a sensing notification request to the terminal according to the sensing permission subscribed by the terminal, and this sensing notification request can be used to request the terminal to reply whether it agrees to be sensed. The terminal can reply agree or disagree to the sensing notification request, that is, the sensing notification feedback of the terminal indicates that the terminal replies agree to be sensed. Correspondingly, the sensing permission of the terminal indicates that it is allowed to be sensed, or, the sensing notification feedback of the terminal indicates that the terminal replies disagree to be sensed. Correspondingly, the sensing permission of the terminal indicates that it is not allowed to be sensed. The terminal can also not reply to the sensing notification request, that is, the sensing notification feedback of the terminal indicates that the terminal does not reply. At this time, it can be combined with the sensing permission subscribed by the terminal to determine: if the sensing permission subscribed by the terminal is that it is necessary to notify the terminal that it is allowed to be sensed when the terminal replies agree or does not reply, then the sensing permission of the terminal indicates that the terminal is allowed to be sensed; if the sensing permission subscribed by the terminal is that it is necessary to notify the terminal that it is allowed to be sensed only when the terminal replies agree, then the sensing permission of the terminal indicates that the terminal is not allowed to be sensed.

[0020] As described above, whether the terminal is allowed or not allowed to be sensed is determined according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal.

[0021] In combination with the first aspect, in some possible implementation manners of the first aspect, the sensing permission subscribed by the terminal includes one or more of the following: allowed to be sensed, not allowed to be sensed, allowed to be sensed and needs to notify the terminal but no reply from the terminal is required, needs to notify the terminal and is allowed to be sensed when the terminal replies consent or does not reply, or needs to notify the terminal and is allowed to be sensed only when the terminal replies consent.

[0022] These different sensing permissions can meet the different security requirements of different terminals, which enables the network (such as the SF or the sensing server) to respond flexibly according to different security requirements.

[0023] Of course, these enumerations are only examples. The sensing permission subscribed by the terminal can be any one of the above-listed items, or can also be other permissions, which are included but not limited to in this application.

[0024] Furthermore, the sensing permission subscribed by the terminal can correspond to at least one area, and / or the sensing permission subscribed by the terminal can correspond to at least one time period.

[0025] The sensing permission subscribed by the terminal can be different due to different locations and / or times. For example, the sensing permission subscribed by the terminal is different in area 1 and area 2, or the sensing permission subscribed by the terminal is different in time period 1 and time period 2, etc., and will not be enumerated any further.

[0026] By setting the sensing permissions of the same terminal at different locations and / or different time periods, the security requirements of the terminal can be further met, enabling the second communication device to respond more flexibly to the sensing request according to the sensing permission of the terminal.

[0027] In combination with the first aspect, in some possible implementation manners, the target service requirement is related to the sensing permission of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be sensed, and / or the target service requirement is determined according to the sensing permission of the terminal.

[0028] Among them, the target service requirement is obtained when it is determined that the terminal is allowed to be sensed, that is, when it is determined that the terminal is allowed to be sensed, the target service requirement is obtained; when it is determined that the terminal is not allowed to be sensed, the target service requirement is not obtained. And whether the terminal is allowed or not allowed to be sensed is determined by the sensing permission of the terminal, or rather is the sensing permission of the terminal. Therefore, the target service requirement is related to the sensing permission of the terminal.

[0029] Correspondingly, the obtaining of the target service requirement includes: obtaining the target service requirement when it is determined that the terminal is allowed to be sensed.

[0030] Among them, determining that the terminal is allowed to be sensed means that it is determined that the terminal is allowed to be sensed by the sensing permission of the terminal, or in other words, the sensing permission of the terminal indicates that the terminal is allowed to be sensed.

[0031] Optionally, the determining that the terminal is allowed to be sensed includes: determining that the terminal is allowed to be sensed according to the sensing permission subscribed by the terminal and / or the sensing notification feedback, and the sensing notification feedback indicates that the terminal replies to agree to be sensed or the terminal does not reply.

[0032] In other words, whether the terminal is allowed to be sensed can be determined according to the subscribed sensing permission and / or the sensing notification feedback of the terminal.

[0033] It should be understood that several possible implementation manners for determining whether the terminal is allowed to be sensed have been described in detail above for the sensing permission of the terminal. For the specific implementation manner of determining that the terminal is allowed to be sensed, reference can be made to the above, and details will not be repeated.

[0034] Furthermore, the method further includes: sending a sensing notification request, where the sensing notification request is used to request the terminal to reply whether it agrees or disagrees to be sensed; obtaining the sensing notification feedback according to the response message of the sensing notification request.

[0035] That is, the sensing notification feedback of the terminal is obtained by sending a sensing notification request to the terminal. The response message of the sensing notification request can be a response message to the sensing notification request and can be used to indicate the sensing notification feedback. A possible design is that the sensing notification feedback is carried in the response message of the sensing notification request.

[0036] The sensing permission subscribed by the terminal can be obtained from the data management function network element or pre-configured in the second communication device, and this application does not make any limitation in this regard. If the sensing permission subscribed by the terminal is obtained from the data management function network element, optionally, the method further includes: obtaining the sensing permission subscribed by the terminal from the data management function network element.

[0037] The target service requirement is determined according to the sensing permission of the terminal, and can include: the target service requirement is determined according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal, or the target service requirement is determined according to the result of whether the terminal is allowed to be sensed, and the result of whether the terminal is allowed to be sensed is determined according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal. Therefore, alternatively, the target service requirement is determined according to the sensing permission subscribed by the terminal and / or the sensing notification feedback.

[0038] The target service requirements can be determined by a data management function network element (such as a unified data management (UDM) network element) and then sent to the second communication device; or they can be determined by the second communication device.

[0039] The target service requirements can be obtained when it is determined that the terminal is allowed to be sensed, or can also be obtained when it is not determined that the terminal is allowed to be sensed. Multiple possible implementation methods are provided below.

[0040] In a possible implementation method, the target service requirements are obtained from a data management function network element.

[0041] Optionally, obtaining the target service requirements when it is determined that the terminal is allowed to be sensed includes: when it is determined that the terminal is allowed to be sensed, sending a service requirements request to the data management function network element; receiving the target service requirements from the data management function network element, where the target service requirements are determined based on the service requirements request.

[0042] A possible situation is that the service requirements request can be sent to the data management function network element when the second communication device determines that the terminal is allowed to be sensed. In other words, the sending of the service requirements request can be triggered by the condition that the terminal is allowed to be sensed. The data management function network element can determine the target service requirements after receiving the service requirements request and send them to the second communication device. That is to say, the sending of the service requirements request can be used to implicitly indicate that the terminal is allowed to be sensed. When the data management function network element receives the service requirements request, it can default that the terminal is allowed to be sensed.

[0043] Another possible situation is that the service requirements request can also be sent when the second communication device determines the result of whether the terminal is allowed to be sensed, and the service requirements request can indicate whether the terminal is allowed or not allowed to be sensed. In other words, regardless of whether the terminal is allowed to be sensed, the second communication device can send the service requirements request to the data management function network element. The data management function network element can first determine whether the terminal is allowed to be sensed according to the received service requirements request, determine and send the target service requirements to the second communication device when the terminal is allowed to be sensed, and does not have to determine the target service requirements when the terminal is not allowed to be sensed. That is to say, the data management function network element does not necessarily have to determine and send the target service requirements.

[0044] Optionally, the service requirements request carries a sensing notification feedback, and the sensing notification feedback indicates that the terminal replies to the sensing notification request to agree to be sensed or the terminal does not reply. The sensing notification request is used to request the terminal to reply whether it agrees or disagrees to be sensed.

[0045] That is, when it is not determined that the terminal is allowed to be sensed, a target service requirement is obtained from a data management function network element through a service requirement request. The service requirement request carries a sensing notification feedback. That is, the second communication device directly informs the data management function network element of the sensing notification feedback, and the data management function network element determines the target service requirement according to the sensing notification feedback and the sensing permission subscribed by the terminal. The data management function network element can further determine the target service requirement when it is determined that the terminal is allowed to be sensed, or can directly determine the target service requirement according to the sensing permission and the sensing notification feedback subscribed by the terminal.

[0046] Further, the method further includes: sending a sensing notification request for requesting the terminal to reply whether it agrees to be sensed; and obtaining the sensing notification feedback according to the response message of the sensing notification request.

[0047] That is, the sensing notification feedback of the terminal is obtained by sending a sensing notification request to the terminal.

[0048] Optionally, the service requirement request further includes the location information of the terminal and / or the time information of the sensing request. The location information of the terminal is used to indicate the location of the terminal. The location information can be carried in the service requirement request, for example.

[0049] The time information of the sensing request is used to indicate one or more of the following: the time when the first communication device initiates the sensing request, the time when the second communication device receives the sensing request, the time of the requested sensing indicated by the sensing request, or the time when the data management function network element receives the service requirement request. The time information can be carried in the service requirement request, for example, or can be determined by the data management function network element according to the time when it receives the service requirement request. This application does not make a limitation in this regard.

[0050] By carrying the location information of the terminal and / or the time information of the sensing request in the service requirement request, the determination of the target service requirement can be further combined with the location information and / or the location information for determination.

[0051] In summary, it is not difficult to see that the target service requirement can be determined based on one or more of the information elements (IEs) and / or time information carried in the service requirement request. The information elements include one or more of the following: the sensing permission subscribed by the terminal, the indication that the terminal is allowed to be sensed, the sensing notification feedback, the location information, the time when the sensing request is initiated, or the time when the sensing request is received.

[0052] In another possible implementation manner, the target service requirement is determined by the second communication device.

[0053] Optionally, when it is determined that the terminal is allowed to be sensed, obtaining the target service requirement includes: when it is determined that the terminal is allowed to be sensed, determining the target service requirement according to the location of the terminal and / or the time information of the sensing request.

[0054] That is, when it is determined that the terminal is allowed to be sensed, the second communication device determines the target service requirement by itself.

[0055] Without distinguishing the location of the terminal and the time information of the sensing request, the second communication device can directly determine the target service requirement when the terminal is allowed to be sensed. However, this application is not limited to this. The second communication device can also determine the target service requirement based on the location of the terminal or the time information of the sensing request.

[0056] Among them, the time information of the sensing request is used to indicate one or more of the following: the time when the first communication device initiates the sensing request, the time when the second communication device receives the sensing request, or the time when the sensing request indicates the requested sensing.

[0057] In a specific implementation, the second communication device can determine the target service requirement according to the mapping relationship and the area to which the location of the terminal belongs. The mapping relationship includes the corresponding relationship between at least one service requirement and at least one area. Or, the second communication device can determine the target service requirement according to the mapping relationship and the time information of the sensing request. The mapping relationship includes the corresponding relationship between at least one service requirement and at least one time period. Or, the second communication device can determine the target service requirement according to the mapping relationship, the time information of the sensing request, and the area to which the location of the terminal belongs. The mapping relationship includes the corresponding relationship between at least one service requirement and at least one combination of area and time period.

[0058] Optionally, the obtaining the target service requirement includes: determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and the mapping relationship. The sensing notification feedback indicates that the terminal replies to the sensing notification request to agree to be sensed or the terminal does not reply to the sensing notification request. The sensing notification request is used to request the terminal to reply whether it agrees to be sensed. The mapping relationship includes the corresponding relationship between at least one combination of sensing permission and sensing notification feedback and at least one service requirement.

[0059] That is, when it is not determined that the terminal is allowed to be sensed, the second communication device can also directly determine the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and the mapping relationship.

[0060] It can be understood that when it is not determined that the terminal is allowed to be sensed, it is also possible that the target service requirement cannot be obtained. At this time, the target service requirement can be regarded as a rejection of the sensing request, or in other words, the rejection of the sensing request is regarded as a kind of target service requirement.

[0061] The mapping relationship may be received from a data management function network element or pre-configured in the second communication device, and this application does not limit this. If it is received from a data management function network element, optionally, the method further includes: receiving the mapping relationship from the data management function network element.

[0062] Further, in the above mapping relationship, each combination in at least one combination of the sensing permission and the sensing notification feedback may correspond to one or more service requirements, and the one or more service requirements correspond to one or more regions. Accordingly, determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and the mapping relationship includes: determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, the region to which the location of the terminal belongs, and the mapping relationship.

[0063] That is to say, the terminal may have different service requirements in different regions, and the second communication device may further determine the target service requirement in combination with the region to which the location of the terminal belongs.

[0064] Alternatively, in the above mapping relationship, each combination in at least one combination of the sensing permission and the sensing notification feedback may correspond to one or more service requirements, and the one or more service requirements correspond to one or more time periods. Accordingly, determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and the mapping relationship includes: determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, the time information of the sensing request, and the mapping relationship.

[0065] As mentioned above, the time information of the sensing request is used to indicate one or more of the following: the time when the first communication device initiates the sensing request, the time when the second communication device receives the sensing request, or the time of the requested sensing indicated by the sensing request.

[0066] That is to say, in different time periods, the terminal may also have different service requirements, and the second communication device may further determine the target service requirement in combination with the time period to which the time when the sensing request is initiated or received or the time of the requested sensing belongs.

[0067] In summary, it can be seen that the target service requirement can be determined according to one or more of the sensing permission of the terminal, the sensing notification feedback, the location of the terminal, or the time information. In other words, the target service requirement can be determined according to the mapping relationship, and the mapping relationship may include the corresponding relationship between at least one service requirement and at least one combination of one or more of the following: the sensing permission subscribed by the terminal, the sensing notification feedback, the region, or the time period.

[0068] As can be seen from the various possible implementation manners of determining the target service requirements provided above, whether the target service requirements are obtained when it is determined that the terminal is allowed to be sensed or when it is not determined that the terminal is allowed to be sensed, the target service requirements are related to the sensing permission of the terminal. Specifically, whether the terminal is allowed to be sensed needs to be determined according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal. Even when the target service requirements are obtained without determining whether the terminal is allowed to be sensed, the target service requirements also need to be determined according to the sensing permission subscribed by the terminal and the sensing notification feedback of the terminal. Therefore, generally speaking, the target service requirements are related to the sensing permission of the terminal.

[0069] In addition, the determination of the target service requirements can also be combined with the location and / or time information of the terminal to be determined, so as to provide richer service requirements for the sensing request and meet the security requirements of the terminal.

[0070] Optionally, the above mapping relationship corresponds to the terminal.

[0071] That is, for the same service type, the mapping relationships of different terminals can be the same or different.

[0072] The above sensing request also carries the identifier of the terminal requesting sensing. The mapping relationship can be a set of mapping relationships corresponding to the terminal determined from at least one set of pre-configured mapping relationships corresponding to at least one terminal.

[0073] In a possible design, the above mapping relationship is pre-configured in the second communication device.

[0074] In another possible design, the above mapping relationship is obtained from the data management function network element. Accordingly, the method further includes: receiving the mapping relationship from the data management function network element.

[0075] Defining the corresponding relationship between different terminals and different service requirements in terms of terminals can meet the security requirements of different terminals.

[0076] Optionally, the above mapping relationship corresponds to the requested service type.

[0077] That is, for the same terminal, the mapping relationships of different service types can be the same or different.

[0078] The above sensing request also indicates the requested service type. The mapping relationship can be a set of mapping relationships corresponding to the requested service type determined from at least one set of pre-configured mapping relationships corresponding to at least one service type.

[0079] Defining the corresponding relationship between different service types and different service requirements in terms of service types can meet different service requirements.

[0080] Optionally, the above mapping relationship corresponds to the terminal and the requested service type.

[0081] That is to say, the above mapping relationship can be a set of mapping relationships determined from multiple pre-configured sets of mapping relationships corresponding to at least one terminal and at least one service type, and corresponding to the terminal and the requested service type.

[0082] By defining the corresponding relationship with different service requirements for different terminals and different service types, both the security requirements of different terminals and different service requirements are taken into account, so that the perception request can be responded to more flexibly.

[0083] Combined with the first aspect, in some possible implementation manners of the first aspect, the perception request comes from a first communication device, and the requested service requirement is also carried in the perception request. The method further includes: sending a service requirement confirmation request to the first communication device, where the service requirement confirmation request is used to request to adopt a target service requirement, and the target service requirement is different from the requested service requirement; receiving a service requirement confirmation reply from the first communication device, where the service requirement confirmation reply indicates whether to agree or disagree to adopt the target service requirement; in the case where the service requirement confirmation reply indicates agreeing to adopt the target service requirement, initiating a perception process for the terminal based on the target service requirement; or, in the case where the service requirement confirmation reply indicates disagreeing to adopt the target service requirement, sending a rejection message to the first communication device, where the rejection message is used to reject the perception request.

[0084] The second communication device can further confirm with the first communication device whether to agree to adopt the target service requirement when the target service requirement is different from the requested service requirement.

[0085] One possible situation is that the sending of the service requirement confirmation request to the first communication device includes: sending a service requirement confirmation request to the first communication device when the level of the target service requirement is lower than the requested service requirement.

[0086] That is to say, in the case of service requirement downgrading, further confirm with the first communication device whether to agree to the downgrade.

[0087] Another possible situation is that the sending of the service requirement confirmation request to the first communication device includes: sending a service requirement confirmation request to the first communication device when the level of the target service requirement is higher than the requested service requirement.

[0088] That is to say, in the case of service requirement upgrading, further confirm with the first communication device whether to agree to the upgrade.

[0089] As can be seen from the above, the determination of the target service requirements takes into account both the security requirements of the terminal and the requirements of the first communication device, and can provide a better user experience.

[0090] Optionally, the method further includes: when it is determined that the terminal is not allowed to be sensed, sending a rejection message to the first communication device, where the rejection message is used to reject the sensing request.

[0091] The situation where the terminal is not allowed to be sensed has been described in detail above in combination with the sensing permission of the terminal, and will not be elaborated here.

[0092] The rejection message and the rejection message sent by the second communication device when the first communication device does not agree to adopt the target service requirements in the above text can be messages with the same function, but the reasons for triggering the second communication device to send the rejection message are different, and either of them can be sent.

[0093] Furthermore, the reason for rejecting the sensing request is carried in the rejection message.

[0094] Exemplarily, the reason for rejecting the sensing request can be that the terminal is not allowed to be sensed, or the first communication device does not agree to adopt the target service requirements, etc., and will not be listed one by one.

[0095] In a second aspect, a sensing method is provided. This method can be applied to a data management function network element (such as UDM). The execution subject of this method can be, for example, a data management function network element, or a component configured in the data management function network element, such as a processor, a chip, a chip system, etc., or a logic module or software that can implement all or part of the functions of the communication device. This application does not make a limitation in this regard.

[0096] The method includes: receiving a service requirement request from a second communication device, where the service requirement request is used to request to obtain a target service requirement, and the target service requirement is used to determine the KPI for sensing the terminal; determining the target service requirement, where the target service requirement is related to the sensing permission of the terminal, and the sensing permission of the terminal is used to determine whether the terminal is allowed or not allowed to be sensed; sending the target service requirement to the second communication device.

[0097] In this solution, the second communication device can be, for example, an SF network element or a sensing server. The second communication device can request the target service requirement from the data management function network element. Since the data management function network element pre-stores the subscription data of the terminal, such as the sensing permission subscribed by the terminal, and other information that can be used to determine the target service requirement, such as a mapping relationship. Therefore, the data management function network element can determine the target service requirement corresponding to the terminal and send it to the second communication device.

[0098] Optionally, the sensing permission of the terminal includes: the sensing permission subscribed by the terminal, the sensing notification feedback of the terminal, or the result of whether the terminal is allowed to be sensed determined by the sensing permission subscribed by the terminal and the sensing notification feedback of the terminal.

[0099] The sensing permission of the terminal, the sensing permission subscribed by the terminal, the sensing notification feedback of the terminal, and the result of whether the terminal is allowed to be sensed determined by the sensing permission subscribed by the terminal and the sensing notification feedback of the terminal have been described in detail in the first aspect. For relevant descriptions in the first aspect, please refer to them and will not be elaborated here.

[0100] Optionally, the target service requirement is related to the sensing permission of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be sensed, or the target service requirement is determined according to the sensing permission of the terminal.

[0101] Whether the terminal is allowed or not to be sensed is determined by the sensing permission of the terminal, or in other words, it is the sensing permission of the terminal. Therefore, generally speaking, the target service requirement is related to the sensing permission of the terminal.

[0102] For the description of the relationship between the target service requirement and the sensing permission of the terminal, please refer to the relevant descriptions in the first aspect and will not be elaborated here.

[0103] Combined with the second aspect, in some possible implementation manners, the service requirement request indicates that the terminal is allowed to be sensed, and determining the target service requirement includes: determining the default service requirement as the target service requirement. Herein, the default service requirement may be a pre-configured service requirement or a requested service requirement, and this application does not make any limitation thereto.

[0104] That is to say, when the terminal is allowed to be sensed, the target service requirement can be directly determined. The determination of the target service requirement is relatively simple and convenient.

[0105] Optionally, the service requirement request further carries one or more of the following: location information, time information of the sensing request, or time information of the service requirement request, and the sensing request is used to request sensing of the terminal; determining the target service requirement includes: determining the target service requirement according to the service requirement request.

[0106] In other words, the data management function network element can determine the target service requirement according to the area where the location of the terminal belongs and the mapping relationship, and the mapping relationship indicates the corresponding relationship between at least one service requirement and at least one area; and / or the data management function network element can determine the target service requirement according to one of the time information of the sensing request or the time information of the service requirement request and the mapping relationship, and the mapping relationship indicates the corresponding relationship between at least one service requirement and at least one time period.

[0107] The location information is used to indicate the location of the terminal. The time information of the sensing request is used to indicate: the time when the first communication device initiates the sensing request or the time when the second communication device receives the sensing request. The time information of the service requirement request is used to indicate: the time when the second communication device sends the service requirement request or the time when the data management functional network element receives the service requirement request.

[0108] Combined with the second aspect, in some possible implementation manners, the service requirement request carries a sensing notification feedback of the terminal, and the sensing notification feedback indicates that the terminal agrees to be sensed in response to the sensing notification request or the terminal does not respond to the sensing notification request, and the sensing notification request is used to request the terminal to reply whether it agrees to be sensed; and, determining the target service requirement includes: determining the target service requirement according to the sensing permission of the terminal, the sensing notification feedback, and the mapping relationship, where the mapping relationship includes the corresponding relationship between at least one combination of the sensing permission and the sensing notification feedback and at least one service requirement.

[0109] That is to say, in the case where it is not determined that the terminal is allowed to be sensed, the target service requirement can also be determined. The data management functional network element can determine the target service requirement according to the sensing notification feedback and the sensing permission subscribed by the terminal. And the data management functional network element can further determine the target service requirement in the case where it is determined that the terminal is allowed to be sensed, or can directly determine the target service requirement according to the sensing permission subscribed by the terminal and the sensing notification feedback.

[0110] Optionally, the service requirement request further carries one or more of the following: location information, time information of the sensing request, or time information of the service requirement request, and the sensing request is used to request to sense the terminal; determining the target service requirement includes: determining the target service requirement according to the location of the terminal and / or the time information of the sensing request.

[0111] For the relevant descriptions of the location information and the time information, reference can be made to the above, and details are not described again.

[0112] In summary, it is not difficult to see that the target service requirement can be determined according to one or more of the IEs carried in the service requirement request and / or the time information. Among them, the cell includes one or more of the following: indication that the terminal is allowed to be sensed, sensing notification feedback, location information, time when the sensing request is initiated, or time when the sensing request is received.

[0113] Or rather, the target service requirement can be determined according to one or more of the sensing permission of the terminal, the sensing notification feedback, the location of the terminal, or the time information. In other words, the target service requirement can be determined according to the mapping relationship, and the mapping relationship can include the corresponding relationship between at least one service requirement and at least one combination of one or more of the following: sensing permission subscribed by the terminal, sensing notification feedback, area, or time period.

[0114] As can be seen from the two possible implementation manners of determining the target service requirement provided above, the determination of the target service requirement is not only related to the sensing permission of the terminal, but also can be determined in combination with the location and / or time information of the terminal, so that richer service requirements can be provided for the sensing request to meet the security requirements of the terminal.

[0115] Optionally, the above mapping relationship corresponds to the terminal.

[0116] Optionally, the above mapping relationship corresponds to the service type of the request.

[0117] Optionally, the above mapping relationship corresponds to the terminal and the service type of the request.

[0118] The relevant content regarding the mapping relationship corresponding to the terminal and / or the service type of the request has been described in detail in the first aspect above. For details, please refer to the relevant description in the first aspect and will not be elaborated here.

[0119] Combined with the second aspect, in some possible implementation manners of the second aspect, before receiving the service requirement request from the second communication device, the method further includes: receiving a sensing authorization request for requesting authorization for a sensing request for sensing the terminal; and sending a sensing authorization reply according to the sensing permission subscribed by the terminal, where the sensing authorization reply indicates authorization for the sensing request or refusal to authorize the sensing request.

[0120] The data management function network element can perform a preliminary screening on the sensing request according to the sensing permission subscribed by the terminal, so that the sensing request for a terminal that is not allowed to be sensed is directly rejected without having to be sent to the second communication device. Thereby, the signaling overhead caused by sending the sensing request to the second communication device subsequently, the processing amount for the second communication device to determine whether the terminal is allowed to be sensed, and the signaling overhead and processing amount for obtaining the target service requirement can be reduced.

[0121] Optionally, the sensing authorization reply indicates authorization for the sensing request, and the sensing authorization reply carries the sensing permission subscribed by the terminal and / or the mapping relationship for determining the target service requirement, where the target service requirement is used to determine the KPI for sensing the terminal.

[0122] When determining to authorize the sensing request, the data management function network element can forward the sensing permission subscribed by the terminal and / or the mapping relationship to the second communication device through the third communication device by means of the sensing authorization reply, that is, the sensing authorization reply and the sensing request sent by the third communication device to the second communication device can be reused, thereby reducing the signaling overhead.

[0123] Optionally, the sensing authorization response indicates a refusal to authorize the sensing request, and the sensing authorization response indicates the reason for the refusal.

[0124] When the data management function network element determines that the authorization for the sensing request is refused, the reason for the refusal is also indicated to the third communication device through the sensing authorization response, so as to facilitate the third communication device to provide the reason for the refusal to the first communication device. For example, the reason for the refusal is that the terminal is not allowed to be sensed. This can avoid the first communication device from initiating a sensing request for the terminal again and reduce signaling overhead.

[0125] In a third aspect, a sensing method is provided. This method can be applied to a data management function network element (such as a UDM). The communication device can be, for example, a data management function network element, or a component configured in the data management function network element, such as a processor, a chip, a chip system, etc., or a logical module or software that can implement all or part of the functions of the communication device. This application does not make any limitations in this regard.

[0126] The method includes: receiving a sensing authorization request, where the sensing authorization request is used to request authorization for a sensing request, and the sensing request is used to request sensing of a terminal; and sending a sensing authorization response according to the sensing permission subscribed by the terminal, where the sensing authorization response indicates authorization for the sensing request or refusal to authorize the sensing request.

[0127] In this solution, the data management function network element can perform a preliminary screening on the sensing request according to the sensing permission subscribed by the terminal, so that the sensing request for a terminal that is not allowed to be sensed is directly refused without being sent to the second communication device. This can reduce the signaling overhead caused by sending subsequent sensing requests to the second communication device, the processing volume for the second communication device to determine whether the terminal is allowed to be sensed, and the signaling overhead and processing volume for obtaining the target service requirements.

[0128] In combination with the third aspect, in some possible implementation manners, the sensing authorization response indicates authorization for the sensing request, and the sensing authorization response carries the sensing permission subscribed by the terminal and / or the mapping relationship for determining the target service requirements, where the target service requirements are used to determine the KPIs for sensing the terminal.

[0129] When the data management function network element determines that the authorization for the sensing request is granted, the data management function network element can forward the sensing permission subscribed by the terminal and / or the mapping relationship to the second communication device through the third communication device by means of the sensing authorization response, that is, the sensing authorization response and the sensing request sent by the third communication device to the second communication device can be reused, thereby reducing signaling overhead.

[0130] In combination with the third aspect, in some possible implementation manners, the sensing authorization reply indicates a refusal to authorize the sensing request, and the sensing authorization reply indicates the reason for the refusal.

[0131] When the data management function network element determines that it refuses to authorize the sensing request, it also indicates the reason for the refusal to the third communication device through the sensing authorization reply, so as to facilitate the third communication device to provide the reason for the refusal to the first communication device. For example, the reason for the refusal is that the terminal is not allowed to be sensed. This can avoid the first communication device from initiating a sensing request for the terminal again and reduce signaling overhead.

[0132] In combination with the second aspect or the third aspect, in some possible implementation manners, the sensing permissions subscribed by the terminal include one or more of the following: allowed to be sensed, not allowed to be sensed, allowed to be sensed and need to notify the terminal but no reply from the terminal is required, need to notify the terminal and allowed to be sensed when the terminal replies consent or does not reply, or need to notify the terminal and allowed to be sensed only when the terminal replies consent.

[0133] For the relevant description of the sensing permissions subscribed by the terminal, reference can be made to the relevant description in the first aspect, which will not be elaborated here.

[0134] The fourth aspect provides a sensing method, which can be applied to the first communication device. The first communication device can be, for example, an AF network element or an AS, or a server integrating the functions of AF and AS, or a component configured in an AF network element, an AS or a server, such as a processor, a chip, a chip system, etc., or a logic module or software capable of implementing all or part of the functions of the first communication device. This application does not make any limitations in this regard.

[0135] The method includes: receiving a service requirement confirmation request from a second communication device, where the service requirement confirmation request is used to request to adopt a target service requirement, and the target service requirement is different from the requested service requirement; sending a service requirement confirmation reply to the second communication device, where the service requirement confirmation reply indicates whether to agree or disagree to adopt the target service requirement.

[0136] When the target service requirement is different from the requested service requirement, the second communication device can further confirm with the first communication device whether to agree to adopt the target service requirement. A possible implementation manner is that the target service requirement is carried in the service requirement confirmation request. The first communication device can determine whether to agree to adopt the target service requirement according to the target service requirement carried in the service requirement confirmation request. Therefore, the determination of the target service requirement takes into account the security requirements of the terminal and the requirements of the first communication device, and can provide a better user experience.

[0137] In combination with the fourth aspect, in some possible implementation manners of the fourth aspect, the method further includes: receiving a rejection message from a first communication device, where the rejection message is used to reject the sensing request.

[0138] It can be understood that the rejection message is sent by the first communication device when the service requirement confirmation reply indicates disagreement with adopting the target service requirement.

[0139] Optionally, the rejection message indicates the reason for rejection.

[0140] Exemplarily, the reason for rejection is that the first communication device disagrees with adopting the target service requirement.

[0141] A fifth aspect provides a sensing method, which can be applied to a system including a data management function network element and a second communication device.

[0142] The method includes: the second communication device receives a sensing request, where the sensing request is used to request sensing of a terminal; the second communication device obtains a target service requirement from the data management function network element, where the target service requirement is used to determine a KPI for sensing the terminal.

[0143] In combination with the fifth aspect, in some possible implementation manners, the second communication device obtaining a target service requirement from the data management function network element includes: when the second communication device determines that the terminal allows to be sensed, the second communication device sends a service requirement request to the data management function network element, where the service requirement request indicates that the terminal allows to be sensed; the data management function network element determines the target service requirement; the data management function network element sends the target service requirement to the second communication device.

[0144] Optionally, the target service requirement carries one or more of the following: location information, time information of the sensing request, or time information of the service requirement, where the sensing request is used to request sensing of the terminal; the data management function network element determining the target service requirement includes: the data management function network element determines the target service requirement according to the target service requirement.

[0145] In a specific implementation, the data management function network element can determine the target service requirement according to the area to which the terminal's location belongs and the mapping relationship, where the mapping relationship includes the corresponding relationship between at least one service requirement and at least one area. Alternatively, the data management function network element can determine the target service requirement according to the time information of the sensing request and / or the time information of the service requirement request, and the mapping relationship, where the mapping relationship includes the corresponding relationship between at least one service requirement and at least one time period. Alternatively, the data management function network element can determine the target service requirement according to one or more of the area to which the terminal's location belongs, the time information of the sensing request, or the time information of the service requirement request, and the mapping relationship, where the mapping relationship includes the corresponding relationship between at least one service requirement and at least one combination of an area and a time period.

[0146] Combined with the fifth aspect, in some possible implementation manners, the method further includes: the second communication device determines that the terminal allows to be sensed.

[0147] Optionally, the second communication device determines that the terminal allows to be sensed, including: the second communication device determines that the terminal allows to be sensed according to the sensing permission subscribed by the terminal and / or the sensing notification feedback, where the sensing notification feedback indicates that the terminal replies to agree to be sensed or the terminal does not reply.

[0148] Optionally, the method further includes: the second communication device obtains the sensing permission subscribed by the terminal from the data management function network element.

[0149] Combined with the fifth aspect, in some possible implementation manners, the second communication device obtains the target service requirement from the data management function network element, including: the second communication device sends a sensing notification request to the terminal, where the sensing notification request is used to request the terminal to reply whether it agrees to be sensed; the second communication device obtains the sensing notification feedback according to the response message of the sensing notification request, where the sensing notification feedback indicates that the terminal replies to agree to be sensed or the terminal does not reply; the second communication device sends a service requirement request to the data management function network element, where the service requirement request carries the sensing notification feedback; the data management function network element determines the target service requirement; the data management function network element sends the target service requirement to the second communication device.

[0150] Optionally, the network element with the data management function determines the target service requirements, including: the network element with the data management function determines the target service requirements according to the mapping relationship, and the mapping relationship includes the corresponding relationship between at least one service requirement and at least one combination of one or more of the following: the sensing permission subscribed by the terminal, the sensing notification feedback, the location of the terminal, the time information of the sensing request, or the time information of the service requirement request. In a sixth aspect, a communication device is provided, which can implement the sensing method described in any one of the first to fourth aspects and any possible implementation manner of the first to fourth aspects. The device includes one or more corresponding functional units or modules for executing the above method. The functional units or modules included in the device can be implemented in software and / or hardware manners.

[0151] In a seventh aspect, a communication device is provided, including a processor, and the processor is used to execute the sensing method described in any one of the first to fourth aspects and any possible implementation manner of the first to fourth aspects.

[0152] Optionally, the device may further include a memory for storing instructions and data. The memory is coupled to the processor, and when the processor executes the instructions stored in the memory, the method described in the above aspects can be implemented.

[0153] Optionally, the device may further include a communication interface, and the communication interface is used for the device to communicate with other devices. Exemplarily, the communication interface may be a transceiver, a circuit, a bus, a module, or other types of communication interfaces.

[0154] In an eighth aspect, a chip system is provided, and the chip system includes at least one processor for supporting the implementation of the functions involved in any one of the first to fourth aspects and any possible implementation manner of the first to fourth aspects. For example, receiving or processing the data and / or information involved in the above method.

[0155] In a possible design, the chip system further includes a memory, and the memory is used to save program instructions and data, and the memory is located inside or outside the processor.

[0156] In a possible design, the chip system further includes an interface circuit and / or a power supply circuit, the interface circuit is used to transmit data, and the power supply circuit is used to supply power to the chip system.

[0157] The chip system may be composed of chips or may include chips and other discrete devices.

[0158] In a ninth aspect, a communication system is provided, which includes one or more of the aforementioned first communication device, second communication device, or data management functional network element. The second communication device can be used to implement the functions involved in the above first aspect and any possible implementation manner of the first aspect. The data management functional network element can be used to implement the functions involved in the above second or third aspect and any possible implementation manner of the second or third aspect. The first communication device can be used to implement the functions involved in the above fourth aspect and any possible implementation manner of the fourth aspect.

[0159] Optionally, the communication system can be used to implement the method in the above fifth aspect and any possible implementation manner of the fifth aspect.

[0160] In a tenth aspect, a computer-readable storage medium is provided, including a computer program, which, when running on a computer, enables the computer to implement the methods in the first to fifth aspects and any possible implementation manner of the first to fifth aspects.

[0161] In an eleventh aspect, a computer program product is provided. The computer program product includes: a computer program (which can also be referred to as code or instructions), which, when the computer program is run, enables the computer to execute the methods in the first to fifth aspects and any possible implementation manner of the first to fifth aspects.

[0162] It should be understood that the fifth to eleventh aspects of this application correspond to the technical solutions of the first to fourth aspects of this application. The beneficial effects obtained by each aspect and the corresponding feasible implementation manners are similar and will not be elaborated here. Description of the Drawings

[0163] Figure 1 are schematic diagrams of two possible architectures in a fifth-generation (5G) network;

[0164] Figure 2 is a schematic diagram of a network architecture based on a service-based architecture (SBA) provided by an embodiment of this application;

[0165] Figure 3 is a schematic diagram of a base station performing a sensing operation;

[0166] Figure 4 is a parameter schematic diagram of sensing accuracy and resolution;

[0167] Figure 5 is a schematic flowchart of a sensing method provided by an embodiment of this application;

[0168] Figure 6 is another schematic flowchart of a sensing method provided by an embodiment of this application;

[0169] Figure 7 is another schematic flowchart of the sensing method provided by the embodiments of the present application;

[0170] Figure 8 is yet another schematic flowchart of the sensing method provided by the embodiments of the present application;

[0171] Figure 9 is yet another schematic flowchart of the sensing method provided by the embodiments of the present application;

[0172] Figure 10 is a schematic block diagram of a communication device provided by the embodiments of the present application;

[0173] Figure 11 is another schematic block diagram of a communication device provided by the embodiments of the present application. Detailed implementation manners

[0174] Next, the technical solutions provided by the present application will be described with reference to the accompanying drawings.

[0175] The method provided by the present application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, 5G mobile communication systems or New Radio Access Technology (NR). Among them, the 5G mobile communication system can include Non-Standalone (NSA) and / or Standalone (SA).

[0176] The technical solution provided by this application can also be applied to machine type communication (MTC), long term evolution - machine (LTE - M), device - to - device (D2D) network, machine - to - machine (M2M) network, internet of things (IoT) network or other networks. Among them, the IoT network can include, for example, the vehicle - to - everything (V2X) network. Among them, the communication methods in the V2X network system are collectively referred to as the vehicle - to - X (V2X, where X can represent anything) system. For example, the V2X can include: vehicle - to - vehicle (V2V) communication, vehicle - to - infrastructure (V2I) communication, vehicle - to - pedestrian (V2P) communication, or vehicle - to - network (V2N) communication, etc.

[0177] The technical solution provided by this application can also be applied to future communication systems, such as the 6th Generation (6G) mobile communication system, etc. This application does not make any limitations in this regard.

[0178] For ease of understanding, first, the network architecture applicable to the method provided in the embodiments of this application will be described in more detail with reference to the accompanying drawings.

[0179] Figure 1 Figures a) and b) in [reference] respectively show two possible architectures in the 5G network: the integrated architecture (see a) in [reference]) and the stand - alone architecture (see b) in [reference]). The difference between the integrated architecture and the stand - alone architecture lies in the location where the sensing service - specific SF is deployed. Figure 1 Figures a) and b) in [reference] respectively show two possible architectures in the 5G network: the integrated architecture (see a) in [reference]) and the stand - alone architecture (see b) in [reference]). The difference between the integrated architecture and the stand - alone architecture lies in the location where the sensing service - specific SF is deployed. Figure 1 Figures a) and b) in [reference] respectively show two possible architectures in the 5G network: the integrated architecture (see a) in [reference]) and the stand - alone architecture (see b) in [reference]). The difference between the integrated architecture and the stand - alone architecture lies in the location where the sensing service - specific SF is deployed.

[0180] As Figure 1 shown in a) of [reference], in the integrated architecture, the SF can be deployed in the traditional 5G core network (5GCN), and is connected to other network elements using the serving - based architecture (SBA) interface. For a more detailed description of SBA, reference can be made to Figure 2 , which will not be elaborated here for the time being. The SF is connected to the NEF and can interact with servers outside the 5GC through the NEF, such as receiving sensing request messages from external servers. The SF can also be connected to the UPF, and RAN devices such as base stations can send the received sensing data to the SF for processing through the user plane.

[0181] As Figure 1 shown in b) of [], in the stand-alone architecture, the SF deployment can be outside the traditional 5GC. The SF and other network elements cannot be connected using the SBA interface and may need to interact with other 5GC network elements through the transit of the NEF (such as NEF 1 in the figure). On the one hand, the SF can also be connected to the NEF (such as NEF 2 in the figure) to interact with external servers through the NEF. Alternatively, the SF can directly interact with external servers without going through the NEF transit. On the other hand, the SF can be connected to the RAN device to interact with the terminal device.

[0182] It should be understood that Figure 1 the two possible architectures shown in a) and b) of [] are only examples using the architecture of the 5GC and should not impose any limitation on this application. The method provided in this application is not limited to being used in the two architectures shown in Figure 1 .

[0183] Figure 2 is a schematic diagram of the SBA network architecture in the 5G network provided by the embodiments of this application. As Figure 2 shown, the 5G network architecture can include three parts, namely the terminal, the data network (DN), and the operator network.

[0184] The following makes a simple description of the network elements involved in Figure 1 and Figure 2 .

[0185] The terminal can also be referred to as a user equipment (UE), access terminal, user unit, user station, mobile station, mobile platform, remote station, remote terminal, mobile device, user terminal, terminal device, wireless communication device, user agent, or user device.

[0186] The terminal is a device with wireless transceiver functions. The terminal can communicate with one or more core network (CN) devices (or called core devices) via access network devices (or called access devices) in the radio access network. The terminal device can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on the water surface (such as ships, etc.); it can also be deployed in the air (such as airplanes, balloons, and satellites, etc.).

[0187] The terminal may also be a terminal in an Internet of Things (IoT) system, and may also be referred to as an IoT node. The IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, so as to realize an intelligent network of human-machine interconnection and object-object interconnection. The connection can be through broadband technology or through narrow band (NB) technology. The IoT technology can achieve massive connections, deep coverage, and power saving of terminals through, for example, narrow band technology.

[0188] In the embodiments of the present application, the device for implementing the functions of the terminal may be the terminal or a device capable of supporting the terminal to implement such functions, such as a chip system. This device may be installed in the terminal or used in matching with the terminal. In the embodiments of the present application, the chip system may be composed of chips or may include chips and other discrete devices. In the embodiments of the present application, only the case where the device for implementing the functions of the terminal is the terminal is taken as an example for illustration, which does not limit the solutions of the embodiments of the present application.

[0189] The terminal in the present application may be a hardware device, or a software function running on dedicated hardware or a software function running on general hardware, or a virtualized device. For example, it can be implemented through general hardware and instantiated virtualization functions, or through dedicated hardware and instantiated virtualization functions. Among them, the general hardware may be a server, such as a cloud server.

[0190] Among them, the operator network may include one or more of the following network elements: Authentication Server Function (AUSF) network element, Network Exposure Function (NEF) network element, Policy Control Function (PCF) network element, Unified Data Management (UDM) network element, Network Repository Function (NRF) network element, Application Function (AF) network element, Access and Mobility Management Function (AMF) network element, Session Management Function (SMF) network element, User Plane Function (UPF) network element, Network Slice Selection Function (NSSF) network element, and Access Network (AN) (such as Radio Access Network (RAN) network element), etc. In the above operator network, the part except the RAN network element can be called the core network part. For the convenience of description hereinafter, the term "network element" is omitted. For example, the AF network element is abbreviated as AF, the UDM network element is abbreviated as UDM, the SF network element is abbreviated as SF, and so on.

[0191] RAN is a network composed of multiple RAN nodes, which realizes wireless physical layer functions, resource scheduling and wireless resource management, wireless access control, and mobility management functions. 5G-RAN can be connected to the User Plane Function (UPF) through the user plane interface N3 for transmitting data of the terminal device; 5G-RAN establishes a control plane signaling connection with the Access and Mobility Management Function (AMF) through the control plane interface N2 for realizing functions such as radio access bearer control.

[0192] RAN nodes can provide wireless communication function services to connect terminals to the wireless network. RAN nodes can also be called RAN devices, or access network devices, etc.

[0193] In a possible scenario, the RAN node can be a base station, evolved NodeB (eNodeB), access point (AP), transmission reception point (TRP), next generation NodeB (gNB), the next generation base station in a 6th generation (6G) mobile communication system, or a base station in a future mobile communication system. The RAN node can be a macro base station, micro base station or indoor station, relay node or donor node, or a radio controller in a cloud radio access network (CRAN) scenario. Optionally, the RAN node can also be a server.

[0194] In another possible scenario, multiple RAN nodes cooperate to assist a terminal in achieving wireless access, and different RAN nodes respectively implement some functions of a base station. For example, the RAN node can be a central unit (CU), distributed unit (DU), CU-control plane (CP), CU-user plane (UP), or radio unit (RU), etc. The CU and DU can be set separately, or can also be included in the same network element, such as a baseband unit (BBU). The RU can be included in a radio frequency device or radio frequency unit, such as included in a remote radio unit (RRU), active antenna unit (AAU), or remote radio head (RRH).

[0195] In different systems, the CU (or CU-CP and CU-UP), DU, or RU may also have different names, but those skilled in the art can understand their meanings. For example, in an open RAN (O-RAN or ORAN) system, the CU can also be called an open CU (O-CU), the DU can also be called an O-DU, the CU-CP can also be called an O-CU-CP, the CU-UP can also be called an O-CU-UP, and the RU can also be called an O-RU. For the convenience of description, in this application, the CU, CU-CP, CU-UP, DU, and RU are used as examples for description. Any one of the CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0196] In the embodiments of the present application, the device for implementing the functions of the RAN node may be the RAN node itself; or it may be a device capable of supporting the RAN node to implement such functions, such as a chip system, a hardware circuit, a software module, or a combination of a hardware circuit and a software module. This device may be installed in the RAN node or used in combination with the RAN node. In the embodiments of the present application, only the case where the device for implementing the functions of the RAN node is the RAN node is taken as an example for illustration, which does not limit the solutions of the embodiments of the present application.

[0197] The RAN node in the present application may be a hardware device, or a software function running on dedicated hardware, or a software function running on general hardware, or a virtualized device. For example, it can be implemented through general hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions. Among them, the general hardware may be a server, such as a cloud server.

[0198] The SF is mainly responsible for the relevant processing of sensing services. For example, it determines the sensing result based on the obtained sensing data, such as whether there is an intrusion, or calculates the distance, direction, position, etc. of the surrounding reflective objects in the sensing area.

[0199] The AMF is mainly responsible for functions such as terminal authentication, terminal mobility management (MM), network slice selection, and SMF selection; serves as the anchor point for the N1 and N2 signaling connections and provides routing for the N1 / N2 session management (SM) messages to the SMF; maintains and manages the status information of the terminal.

[0200] The SMF is mainly responsible for all control plane functions of terminal session management, including UPF selection, Internet Protocol (IP) address allocation, Quality of Service (QoS) management of the session, obtaining the PCC (Policy and Charging Control) policy (from the PCF), etc.

[0201] The UPF, as the anchor point of the protocol data unit (PDU) session connection, is responsible for filtering terminal data packets, data transmission / forwarding, rate control, generating charging information, etc.

[0202] The UDR is mainly used to store user data, including subscription data called by the UDM, policy information called by the PCF, structured data for capability open, application data called by the NEF, etc.

[0203] The UDM is mainly used to manage user data, such as the management of subscription information, including obtaining subscription information from the UDR and providing it to other network elements (such as the AMF); generating 3GPP authentication credentials for the terminal; registering and maintaining the network elements currently serving the terminal (for example, the AMF represented by AMF ID1 is the current serving AMF of the terminal, serving AMF).

[0204] The NEF is used for the interaction between other internal network elements of the core network and the application function (AF) network element corresponding to the external application server (application server, AS) of the core network, so as to provide network open capabilities to the AF, or provide the information provided by the AF to the core network element.

[0205] The AUSF authentication server function is used to perform security authentication on the terminal when the terminal accesses the network.

[0206] The PCF mainly performs policy control such as service quality (QoS) policies and charging policies. It provides configuration policy information for the terminal and provides policy information for controlling the terminal to the control plane network elements of the network (such as the AMF and SMF).

[0207] The AF mainly transmits the requirements of the application side to the network side and can be regarded as an application server or an agent of the application server. The AF can interact with core network elements to provide some services. For example, it interacts with the PCF for service policy control, interacts with the NEF to obtain some network capability information or provide some application information to the network, and provides some data network access point information to the PCF to generate corresponding data service routing information.

[0208] The DN mainly provides service for users.

[0209] The network elements communicate with each other through interfaces. For example, the interface between the terminal and the AMF is the N1 interface, the interface between the AN and the AMF is the N2 interface, the interface between the AN and the UPF is the N3 interface, the interface between the SMF and the UPF is the N4 interface, and the interface between the UPF and the DN is the N6 interface. Some network elements can communicate based on service-based interfaces. Among them, Figure 1 Nnssf, Nnef, Nnrf, Npcf, Nudm, Naf, Nusf, Namf, Npcf, Nsf are service-based interfaces based on services. Among them, the interface Nsf is only a possible naming, and this application does not limit the name of the service-based interface corresponding to the SF.

[0210] The above descriptions of each network element in the core network and the interfaces between each network element are only exemplary explanations and should not constitute any limitation to this application. In addition, each network element shown in the figure can be understood as a network element in the core network for implementing different functions. For example, they can be combined into network slices as needed. These core network elements can be independent devices respectively, or integrated into the same device to implement different functions. This application does not limit the specific forms of the above network elements.

[0211] It can be understood that the network elements applied in future communication systems can be the above network elements, or network elements with other names having the same or similar functions. This application does not limit this.

[0212] In the embodiments of this application, the devices for implementing the functions of each core network element can be the core network elements corresponding to each function; or they can be devices capable of supporting the core network elements to implement their respective functions, such as chip systems, hardware circuits, software modules, or a combination of hardware circuits and software modules. This device can be installed in the core network element or used in matching with the core network element. In the embodiments of this application, only the case where the device for implementing the core network function is the core network element is taken as an example for explanation, and it does not limit the solutions of the embodiments of this application.

[0213] The core network elements in this application can be hardware devices, or software functions running on dedicated hardware, or software functions running on general hardware, or virtualized devices. For example, they can be implemented through general hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions. Among them, the general hardware can be a server, such as a cloud server.

[0214] Currently, some base stations or terminals in the RAN have the sensing ability brought by electromagnetic waves and can be used as sensing nodes. The implementation of sensing is similar to the principle of radar. That is, a transmitter (i.e., the sensing node) emits electromagnetic waves, and the electromagnetic waves are reflected by the object to be sensed and then acquired by the receiver. The receiver (i.e., the sensing node) can further process the acquired reflected signal (which can be called sensing raw data) to obtain sensing data, and this sensing data can be used to obtain sensing results.

[0215] For example, when a base station is used as a sensing node, it has the functions as shown in Table A and Figure 3 . Among them, Table A is an example of the sensing capabilities of speed measurement radar, surveillance radar, and imaging radar.

[0216] Table A

[0217]

[0218]

[0219] Figure 3It is a schematic diagram of a base station performing sensing operations. Figure 3 It is an example of integrated sensing and communication (ISAC). Figure 3 The base station shown can reuse the electromagnetic wave signals of the communication system for sensing. As shown in the figure, the resources for communication and sensing of the base station can be time-division multiplexed (as Figure 3 shown), or space-division multiplexed. The base station can use electromagnetic wave signals for sensing detection, and can also receive the signals (which can be simply called reflected signals or echo signals for short) that are transmitted back after reaching the obstacle (i.e., the detected target), and obtain sensing data according to the echo signals. As Figure 3 shown, the base station can perform serial-to-parallel conversion, phase shift keying, inverse fast Fourier transform (IFFT), parallel-to-serial conversion, digital-to-analog conversion, etc. on the signal to be transmitted. The base station can also perform analog-to-digital conversion, parallel-to-serial conversion, fast Fourier transform, serial-to-parallel conversion, demodulation, etc. on the received echo signal. The signal to be transmitted can also be sent to the radar processor so that the radar processor can obtain sensing data according to the signal to be transmitted and the received echo signal (it can be understood that the echo signal here is the echo signal after the above processing). It should be understood that Figure 3 the processing performed by the base station shown on the signal to be transmitted and the received echo signal is only an example and should not impose any limitation on this application.

[0220] The sensing nodes in the communication system can sense and identify specified areas, specified objects or events, and meet sensing requirements in multiple aspects such as autonomous driving, security supervision, home health, and meteorological monitoring. Specific examples are as follows:

[0221] I. Autonomous Driving

[0222] In V2X and unmanned aerial vehicle (UAV) scenarios, for example, due to the short sensing distance of vehicles or UAVs or the inability to sense non-line-of-sight (NLOS) paths, a dynamic map can be generated based on the sensing data; for another example, during the driving process of vehicles or UAVs, there may be traffic hazard events such as pedestrians or non-motor vehicles suddenly appearing or pedestrians or non-motor vehicles being in the blind spot of vision. The hazard events can be identified based on the sensing data and the vehicles or UAVs can be notified to perform emergency operations; for another example, in autonomous driving assistance for vehicles or UAVs, a customized high-precision dynamic map can be generated based on the sensing data to assist vehicles or UAVs in autonomous driving.

[0223] II. Safety Supervision

[0224] In the V2X and drone scenarios, it is possible to identify violations of vehicle or drone driving based on perception data, such as a vehicle occupying the emergency lane or a drone deviating from its flight path, etc., and real-time warnings can be executed.

[0225] In the perimeter security scenario, based on perception data, it is possible to detect situations such as foreign objects invading the railway track or drones invading no-fly zones (such as airports), etc., and track the violating objects and execute real-time emergency handling.

[0226] III. Home Health

[0227] For example, it is possible to identify abnormal postures based on perception data, thereby being able to identify situations such as a fall, etc., and give timely warnings; for another example, physiological parameters such as human breathing or heartbeat can be obtained from perception data, thereby being able to identify abnormalities and give timely warnings.

[0228] IV. Meteorological Monitoring

[0229] It is possible to sense and predict environmental, climate, weather changes, etc.

[0230] Figure 4 It is a schematic diagram of parameters affecting perception accuracy and resolution. Figure 4 Taking the vehicle networking scenario as an example, several parameters of perception positioning accuracy (including vertical and horizontal), perception speed accuracy (including vertical and horizontal), and perception resolution (including area and speed) in the KPIs affecting perception are shown.

[0231] 1. Range resolution α: The ability to distinguish adjacent targets in terms of range, usually measured by the minimum resolvable range interval, and used to identify different vehicles.

[0232] 2. Velocity resolution β: The ability to distinguish targets in terms of radial velocity.

[0233] 3. Angle measurement accuracy θ: The ability of the radar to distinguish adjacent targets in terms of angle, usually measured by the minimum resolvable angle.

[0234] 4. Horizontal field of view (FOV): Figure 4 The shown FOV is 120°. Under this 120° FOV, in the case of a two-way road width of 30 meters, the two-way blind zone range is less than 18m, and the blind zone area ratio <1%.

[0235] For the convenience of understanding the embodiments of the present application, the following points are first explained:

[0236] First, in this application, an indication includes an explicit indication (also known as a direct indication) and an implicit indication (also known as an indirect indication). Among them, explicitly indicating information A means including this information A; implicitly indicating information A means indicating information A through the correspondence between information A and information B and directly indicating information B. The correspondence between information A and information B can be predefined, pre-stored, pre-burned, or pre-configured; or, it can also mean indicating information A through information B and a preset rule.

[0237] Second, in this application, information C is used for the determination of information D, which includes both the case where information D is determined only based on information C and the case where it is determined based on information C and other information. In addition, when information C is used for the determination of information D, there can also be an indirect determination situation. For example, information D is determined based on information E, and information E is determined based on information C.

[0238] Third, in this application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship, but it does not exclude the case where the associated objects before and after are in an "and" relationship. The specific meaning represented can be understood in combination with the context. "At least one of the following" or its similar expressions refer to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Among them, a, b, and c can be single or multiple.

[0239] Fourth, in this application, the use of prefix words such as "first" and "second" is only for facilitating the differential description of different things belonging to the same name category and does not restrict the order, size, or quantity of things. For example, "the first communication device" and "the second communication device" are just different communication devices, and there is no size relationship or priority relationship between them.

[0240] Fifth, in this application, "send" and "receive" indicate the direction of signal transmission. For example, "sending information to the terminal" can be understood as the destination of the information being the terminal, which may include directly sending through the air interface or indirectly sending through other units or modules via the air interface. "Receiving information from the terminal" can be understood as the source of the information being the terminal, which may include directly receiving from the terminal through the air interface or indirectly receiving from the terminal through other units or modules via the air interface. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface.

[0241] Sixth, in the embodiments of this application, "when", "if", and "in case" all refer to the device making corresponding processing under certain objective circumstances, not limited to a specific time, and do not require the device to have a judgment action during implementation, nor does it imply any other limitations.

[0242] Seventh, in this application, words such as "example", "exemplarily", "for example", or "such as" are used to give examples, illustrations, or explanations. Any embodiment or design solution described as "example", "exemplarily", "for example", or "such as" in this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, using words such as "example", "exemplarily", "for example", or "such as" is intended to present relevant concepts in a specific manner.

[0243] Eighth, in this application, multiple message names are introduced, such as sensing request, sensing authorization request, sensing authorization reply, service requirement request, service requirement reply, sensing notification request, etc. These messages are only for the convenience of distinguishing examples and should not constitute any limitation to this application. This application does not limit the names of each signaling.

[0244] Ninth, the corresponding relationships shown in each table in this application are only examples and should not constitute any limitation to this application. The content in each table is merely for illustration and can be configured as other content, which is not limited in this application. When configuring these corresponding relationships, it is not necessarily required to configure all the corresponding relationships shown in each table. For example, the corresponding relationships shown in some rows can also not be configured. Also, for example, some columns can be replaced with other forms. Again, for example, appropriate deformation adjustments can be made based on the tables shown in this article, such as splitting, merging, etc.

[0245] In addition, the table is only one possible form of the corresponding relationship. In specific implementations, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash maps, etc.

[0246] In the current sensing process, the AF or AS of the sensing application can send a sensing request message to the NEF to request sensing of a specific terminal. The AF, AS of the sensing application, or the terminal carrying the sensing application can also directly send a sensing request message to the network element responsible for the sensing function in the communication network. In response to the sensing request message, the network element responsible for the sensing function in the communication network (such as the SF or the sensing server) can initiate a sensing process for the specific terminal.

[0247] In the sensing request message for a specific service type or specific terminal, the AF, AS, or terminal usually indicates service requirements, which can be used to describe the needs of the sender of the sensing request message for the sensing result, such as accuracy, resolution, latency, or refresh rate, etc. Different terminals may have different security requirements. Some terminals may not want to expose their own information (such as location or moving speed, etc.) to the outside, and some terminals may not want to expose their own information with a high degree of accuracy to the outside, etc. The AF, AS, or terminal initiating the sensing does not necessarily know in advance the security requirements of each terminal to be sensed. Due to reasons such as simple processing, the SF or the sensing server may directly initiate the sensing of the terminal according to the service requirements in the sensing request message, and cannot flexibly adjust the service requirements adaptively according to the different security requirements of the terminals, thus unable to meet the different security requirements of different terminals. It is not difficult to see that there is no relevant security process for the current sensing process for specific terminals.

[0248] This application provides a sensing method. When the network element responsible for the sensing function (such as the SF or the sensing server) receives a sensing request message for the terminal, it can obtain the service requirements (i.e., the target service requirements below) used for sensing the terminal, and this service requirement is related to the sensing permission of the terminal. Thus, the sensing process initiated for the terminal is adapted to the sensing permission of the terminal, rather than blindly determining the KPI for sensing the terminal directly according to the service requirements requested by the AF network element or AS, etc. Or rather, this application can obtain the target service requirements at the granularity of the terminal. Specifically, the target service requirements of different terminals can be determined according to their respective corresponding sensing permissions. Therefore, considering the security requirements of different terminals, flexibly obtain different target service requirements according to the sensing permissions of different terminals, and then initiate the sensing process for different terminals based on different KPIs, rather than blindly using the same KPI to sense all terminals requested to be sensed according to the service requirements requested by the AF network element or AS.

[0249] The method provided by this application will be described in detail below with reference to the accompanying drawings.

[0250] It should be noted that in the embodiments shown in multiple accompanying drawings below, taking the UDM as an example of the data management function network element, the AF and AS as two examples of the first communication device, and the SF and the perception server as two examples of the second communication device respectively, the method provided by the present application is described. These devices are only examples and should not impose any limitations on the present application. The AF, AS, UDM, SF, perception server, etc. can also be replaced by other network elements that can achieve the same or similar functions, and the present application does not make any limitations in this regard.

[0251] Figure 5 It is a schematic flowchart of the perception method provided by the present application. Figure 5 This method is shown from the perspective of device interaction. As Figure 5 shown, the method 500 includes steps 501 to 513. Figure 5 The SF in can also be replaced by components in the SF, such as chips, chip systems, or processors, etc., or can also be replaced by logic modules or software that can implement part or all of the functions of the SF; Figure 5 The UDM in can also be replaced by components in the UDM, such as chips, chip systems, or processors, etc., or can also be replaced by logic modules or software that can implement part or all of the functions of the UDM; Figure 5 The AF in can also be replaced by components in the AF, such as chips, chip systems, or processors, etc., or can also be replaced by logic modules or software that can implement part or all of the functions of the AF.

[0252] The following details each step in the method 500.

[0253] In step 501, the AF sends a perception request to the NEF, and this perception request is used to request to perceive the terminal.

[0254] Exemplarily, this perception request may carry the external identifier of the terminal to be perceived and one or more of the following: the identifier of the AF, the type of the requested service, the requirements of the requested service, or the time information of the requested perception.

[0255] Among them, the external identifier of the terminal can be used to identify the terminal. Since the AF does not know the identifier of the terminal in this communication system, it is named with the external identifier here for distinction from the identifier of the terminal in the communication system.

[0256] The identifier of the AF is used to identify the AF. It can be understood that when the AF is the AS, the identifier of the AF can also be replaced by the identifier of the AS.

[0257] The requested service type can be one or more of at least one predefined service type. The at least one service type may include, for example, but is not limited to, drone intrusion detection, autonomous driving, security supervision, home health, or meteorological monitoring, etc., and this application includes but is not limited to this.

[0258] The requested service requirements can be used to describe the requirements for the perceived results of the request. For example, the requested service requirements include one or more of the following: perceived location accuracy, perceived speed accuracy, perceived resolution, or the duration required for perception. The service requirements can be used to determine the KPIs corresponding to the perceived results requested by the perception request.

[0259] Exemplarily, in the 3rd generation partnership project (3GPP) technical specification (TS) 22.173, the following metrics are defined for the perception KPIs: confidence interval, perceived positioning accuracy (including vertical and horizontal), perceived speed accuracy (including vertical and horizontal), perceived resolution (including area and speed), maximum perceived service delay, and refresh rate, etc. These parameters can be used to describe the precision with which the perceived data needs to be obtained.

[0260] Of course, these metrics are only an example of the perception KPIs, and this application does not limit the specific metrics included in the perception KPIs.

[0261] The time information for requesting perception can be used for the time of requesting perception. Specifically, the time of requesting perception can refer to the time of requesting to perceive the terminal, or the time of initiating the perception process for the terminal.

[0262] As can be seen from the architectures shown in a) and b) combined with the foregoing Figure 1 the SF may be deployed in a converged architecture or an independent architecture. The AF can send the perception request to the SF through the NEF. Therefore, correspondingly, in step 501, the NEF receives the perception request from the AF.

[0263] In step 502, the NEF obtains authorization for the perception request from the UDM.

[0264] Exemplarily, step 502 may include the following steps 5021 to 5023:

[0265] Step 5021, the NEF sends a perception authorization request to the UDM. The perception authorization request is used to request the UDM to authorize the perception request, or to request the UDM to perform an authorization check on the perception request.

[0266] Step 5022, the UDM determines whether the terminal is allowed or not allowed to be perceived according to the perception permissions subscribed by the terminal.

[0267] Step 5023, the UDM sends a sensing authorization response to the NEF, and the sensing authorization response is used to indicate authorization or rejection of the sensing request.

[0268] The sensing authorization request may carry, for example, the information in the above sensing request, such as the external identifier of the terminal and one or more of the following: the identifier of the AF, the type of service requested, the service requirements requested, or the time information of the requested sensing. In a possible design, the sensing authorization request may be the above sensing request. In another possible design, the sensing authorization request is obtained by processing the above sensing request. This application does not make any limitation in this regard.

[0269] The UDM may determine whether the terminal is allowed or not allowed to be sensed (i.e., whether the terminal allows to be sensed) according to the sensing permissions subscribed by the terminal, and indicate authorization or rejection of the sensing request through the sensing authorization response. When the UDM determines that the terminal is allowed to be sensed, it may indicate authorization of the sensing request through the sensing authorization response, as shown in 5023a in the figure; when it determines that the terminal is not allowed to be sensed, it may indicate rejection of the sensing request through the sensing authorization response, as shown in 5023b in the figure. It can be understood that 5023a and 5023b can be regarded as two possible cases of step 5023, and either one can be executed.

[0270] It can be understood that when the sensing authorization response indicates authorization of the sensing request, the sensing authorization response may also be referred to as an authorization message; when the sensing authorization response indicates rejection of the sensing request, the sensing authorization response may also be referred to as a rejection authorization message.

[0271] Among them, the sensing permissions subscribed by the terminal are the sensing permissions subscribed by the terminal with the network operator, and may also be referred to as configured sensing permissions, or default sensing permissions, or sensing permissions stored on the network side. For example, the terminal can clarify whether it allows to be sensed by subscribing with the operator. The sensing permissions subscribed by the terminal may be pre-configured in the UDM. For example, they can be manually stored in the UDM, or sent to the UDM by the AF in advance. This application does not make any limitation in this regard.

[0272] Exemplarily, the perception permissions subscribed by the terminal may include one of the following multiple permissions: allowed to be perceived, not allowed to be perceived, allowed to be perceived and need to notify the terminal but without the need for the terminal to reply, need to notify the terminal and allowed to be perceived when the terminal replies consent or does not reply, or need to notify the terminal and allowed to be perceived only when the terminal replies consent. Among them, "need to notify the terminal and allowed to be perceived when the terminal replies consent or does not reply" specifically means: need to notify the terminal, allowed to be perceived when the terminal replies consent or does not reply, and not allowed to be perceived when the terminal replies dissent; "need to notify the terminal and allowed to be perceived only when the terminal replies consent" specifically means: need to notify the terminal, allowed to be perceived when the terminal replies consent, and not allowed to be perceived when the terminal replies dissent or does not reply.

[0273] Table 1 shows several possible permissions.

[0274] Table 1

[0275] Index Permission 1 Allowed to be sensed 2 Not allowed to be sensed 3 Allowed to be sensed, need to notify the terminal but no reply is required from the terminal 4 Need to notify the terminal, allowed to be sensed when the terminal replies consent or does not reply 5 Need to notify the terminal, allowed to be sensed only when the terminal replies consent

[0276] For each terminal, the perception permission it subscribes is one of the multiple permissions shown in Table 1. Alternatively, the perception permission subscribed by the terminal may include one of the following multiple permissions: allowed to be perceived, not allowed to be perceived, allowed to be perceived and need to notify the terminal but without the need for the terminal to reply, need to notify the terminal and not allowed to be perceived when the terminal replies dissent or does not reply, or need to notify the terminal and not allowed to be perceived only when the terminal replies dissent. Among them, "need to notify the terminal and not allowed to be perceived when the terminal replies dissent or does not reply" specifically means: need to notify the terminal, not allowed to be perceived when the terminal replies dissent or does not reply; "need to notify the terminal and not allowed to be perceived only when the terminal replies dissent" specifically means: need to notify the terminal, allowed to be perceived when the terminal replies consent or does not reply, and not allowed to be perceived when the terminal replies dissent. The perception permission subscribed by each terminal may also be one of multiple permissions.

[0277] The perception permission subscribed by each terminal can be pre-configured in the UDM, for example, indicated by the index of the permission included in the perception permission subscribed by the terminal's identifier. For example, the perception permission subscribed by terminal 1 is allowed to be perceived, the perception permission subscribed by terminal 2 is not allowed to be perceived, the perception permission of terminal 3 is allowed to be perceived and need to notify the terminal but without the need for the terminal to reply, the perception permission subscribed by terminal 4 is need to notify the terminal and allowed to be perceived when the terminal replies consent or does not reply, and the perception permission subscribed by terminal 5 is need to notify the terminal and allowed to be perceived only when the terminal replies consent. Then the perception permissions subscribed by these five terminals can be as shown in Table 2.

[0278] Table 2

[0279] Terminal Signed sensing permission 1 1 2 2 3 3 4 4 5 5

[0280] Of course, the column of subscribed sensing permissions in Table 2 can also be replaced with the sensing permissions subscribed by each terminal respectively, without being indicated by an index. Table 2 is only an example and should not constitute any limitation to this application.

[0281] In step 5022, if the subscribed sensing permission of the terminal is "allowed to be sensed", or "allowed to be sensed, need to notify the terminal but no response from the terminal is required", the UDM can directly determine that the terminal is allowed to be sensed and can authorize this sensing request. If the subscribed sensing permission of the terminal is "not allowed to be sensed", the UDM can directly determine that the terminal is not allowed to be sensed and can reject the authorization of this sensing request. If the subscribed sensing permission of the terminal is "need to notify the terminal, allowed to be sensed when the terminal replies consent or does not reply", or "need to notify the terminal, allowed to be sensed when the terminal does not reply", or "need to notify the terminal, not allowed to be sensed when the terminal does not reply", or "need to notify the terminal, allowed to be sensed only when the terminal replies consent", the UDM temporarily cannot determine whether the terminal is allowed to be sensed and still needs to combine with the reply of the terminal to determine. At this time, the UDM can authorize this sensing request to facilitate the execution of subsequent processes. It should be noted that the authorization of the sensing request by the UDM does not mean that this sensing request will definitely be executed. Instead, it is to facilitate the execution of subsequent processes and temporarily authorize this sensing request, so as to hand over the determination of whether the terminal is allowed to be sensed to other network elements for execution. For example, in this embodiment, it is handed over to the SF for execution. The SF can determine whether the terminal is allowed to be sensed after receiving the sensing request, and obtain the target service requirements when determining that the terminal is allowed to be sensed, and reject this sensing request when determining that the terminal is not allowed to be sensed. In other words, requesting the UDM to obtain the authorization of the sensing request can be regarded as the UDM performing a preliminary screening on the sensing request, and not necessarily all sensing requests initiated for terminals not allowed to be sensed can be filtered. In the following text, for the sake of simplicity, the description of the same or similar situations is omitted.

[0282] Furthermore, the sensing permissions subscribed by the terminal can correspond to at least one area and / or at least one time period. In other words, the sensing permissions subscribed by the terminal include at least one type of sensing permission corresponding to at least one area, and / or the sensing permissions subscribed by the terminal include at least one type of sensing permission corresponding to at least one time period. Or rather, the sensing permissions subscribed by the terminal can vary according to different locations and / or times. For example, the sensing permissions subscribed by the terminal are different in Area 1 and Area 2, or the sensing permissions subscribed by the terminal are different during Time Period A and Time Period B, and so on, which will not be enumerated here. Exemplarily, the location can include one or more of the following: coordinate information, geographical area identifier, address information, tracking area identifier (TAI), or cell identifier (cell ID).

[0283] Exemplarily, Table 3 shows the corresponding relationships between different permissions, different locations, and different times.

[0284] Table 3

[0285]

[0286] For each terminal, the sensing permissions it subscribes to include one or more groups among the multiple groups of corresponding relationships shown in Table 3. That is to say, the sensing permissions of a terminal can correspond to a specific area and / or a specific time period. Further, a terminal can have the same sensing permissions or different sensing permissions in different areas; it can have the same sensing permissions or different sensing permissions in different time periods.

[0287] It should be understood that Table 3 is only an example and can also be split into two tables, namely, a table for indicating the corresponding relationships between different permissions and different time periods and a table for indicating the corresponding relationships between different permissions and different areas.

[0288] If the sensing permissions subscribed by the terminal include at least one type of sensing permission corresponding to at least one area, since the UDM cannot directly interact with the terminal, the UDM may temporarily not be able to obtain the location of the terminal, so it may not be able to determine the sensing permissions subscribed by the terminal for the time being, and thus may not be able to determine whether the terminal is allowed to be sensed. Therefore, the sensing request can be authorized to execute subsequent processes.

[0289] If the perception permissions subscribed by the terminal include at least one type of perception permission corresponding to at least one time period, the UDM may determine the corresponding perception permission according to the time period to which the time when the perception request is received belongs, and then determine whether the terminal is allowed to be perceived. Of course, the UDM may also need to combine the response of the terminal to determine. Therefore, when the time period to which the time when the perception request is received belongs is within the range of the above at least one time period, and it is necessary to further combine the response of the terminal to determine that the terminal is allowed to be perceived, the perception request can be authorized to execute the subsequent process.

[0290] In summary, it can be seen that the UDM can perform a preliminary screening of the perception request according to the perception permissions subscribed by the terminal, so that the perception requests for terminals that are not allowed to be perceived are directly rejected without having to be sent to the SF. Thereby, the signaling overhead caused by sending perception requests to the SF subsequently can be reduced, as well as the processing volume for the SF to determine whether the terminal is allowed to be perceived and to determine the target service requirements.

[0291] Optionally, when the UDM determines to authorize the perception request, it may determine the identifier of the terminal in the communication system according to the external identifier of the terminal, such as the subscription permanent identifier (SUPI) of the terminal, and carry the SUPI of the terminal in the perception authorization response. In other words, the SUPI of the terminal is carried in the above perception authorization response.

[0292] Optionally, when the UDM determines to authorize the perception request, it may carry the perception permissions subscribed by the terminal and / or the mapping relationship for determining the target service requirements in the perception authorization response. In other words, the perception permissions subscribed by the terminal and / or the mapping relationship for determining the target service requirements are carried in the above perception authorization response. Among them, the mapping relationship for determining the target service requirements may include one or more of the following: the correspondence between at least one service requirement and at least one time period, the correspondence between at least one service requirement and at least one area, or the correspondence between at least one service requirement and at least one combination of time period and area. Since the mapping relationship is described in detail in step 505 later in combination with the first mapping relationship, the second mapping relationship, and the third mapping relationship, it will not be elaborated here for the time being. Optionally, when the UDM determines to reject the authorization of the perception request, it may carry the reason for rejection in the perception authorization response. In other words, the reason for rejection is carried in the above perception authorization response. For example, the reason for rejecting the perception request is that the terminal is not allowed to be perceived.

[0293] In summary, the perception authorization response (or, authorization message) indicates an authorized perception request and carries one or more of the following: the SUPI of the terminal, the perception permissions subscribed by the terminal, or the mapping relationship for determining the target service requirements, as shown in 5023a in the figure. Alternatively, the perception authorization response (or, denied authorization message) indicates a denied perception request and indicates the reason for the denial, as shown in 5023b in the figure.

[0294] The NEF can determine whether to continue sending the perception request to the SF based on the received perception authorization response. If the perception authorization response indicates authorization of the perception request, step 503 can be executed, where the NEF sends the perception request to the SF. If the perception authorization response indicates denial of authorization of the perception request, step 504 can be executed, where the NEF sends a denial message to the AF.

[0295] It should be noted that step 502 is not necessarily mandatory. For example, in the stand-alone architecture shown in b) of Figure 1 , the NEF can directly forward the perception request to the SF without having to request authorization from the UDM. Even in the converged architecture shown in a) of Figure 1 , the NEF can also directly forward the perception request to the SF, and this application does not make any restrictions on this.

[0296] In step 503, the NEF sends a perception request to the SF.

[0297] One possible implementation is that the NEF can directly forward the received perception request to the SF. Therefore, the perception request received by the SF also carries the external identifier of the terminal requesting the perception and one or more of the following: the identifier of the AF, the type of service requested, the service requirements of the request, or the time information of the requested perception.

[0298] Another possible implementation is that the NEF can send the received perception request to the UDM before sending the perception request to the SF, and then forward it to the SF after authorization by the UDM.

[0299] If the NEF has obtained authorization from the UDM through step 502 before step 503, then this step 503 can be executed in the case of receiving an authorization message from the UDM. For ease of understanding, it is assumed in this article that the UDM determines that the terminal is allowed to be perceived and sends an authorization message to the NEF.

[0300] As described above, the sensed authorization response may carry the SUPI of the UE. The NEF may replace the external identifier of the UE in the sensed request received from the AF with the SUPI of the UE according to the SUPI of the UE carried in the sensed authorization response, and send the sensed request with the replaced SUPI of the UE to the SF. The sensed authorization response may also carry the sensed permissions subscribed by the UE and / or the mapping relationship for determining the target service requirements. The NEF may also carry the sensed permissions and / or the mapping relationship for determining the target service requirements carried in the sensed authorization response in the sensed request and send it to the SF. In this case, the sensed request sent by the AF in step 501 may also be referred to as the first sensed request, and the sensed request sent by the NEF in step 502 may be referred to as the second sensed request. It can be understood that both the first sensed request and the second sensed request can be used to request sensing of the UE. The difference is that the identifier of the UE carried in the first sensed request is the external identifier of the UE, and the identifier of the UE carried in the second sensed request is the SUPI of the UE, and the second sensed request may also carry the sensed permissions and / or the mapping relationship for determining the target service requirements. That is to say, the second sensed request carries the SUPI of the UE, and one or more of the following: the identifier of the AF, the type of service requested, the service requirements requested, the sensed permissions subscribed by the UE, or the mapping relationship for determining the target service requirements.

[0301] In summary, the sensed request received by the SF in step 502 may be the first sensed request or the second sensed request. For the convenience of description hereinafter, the first sensed request and the second sensed request are collectively referred to as the sensed request.

[0302] Of course, the UDM may also not carry the SUPI of the UE in the authorization message. In this case, the sensed request sent by the NEF to the SF may be the sensed request received from the AF, and this application does not make any limitation on this.

[0303] In addition, if the authorization for the sensed request has not been obtained from the UDM before step 503 (for example, in the independent architecture shown in b) of Figure 1 , the NEF may directly forward the sensed request to the SF without having to request authorization from the UDM, or the NEF directly forwards the sensed request to the SF), the sensed request sent by the NEF to the SF may also be the sensed request received from the AF.

[0304] In step 504, the NEF sends a rejection message to the AF, and this rejection message is used to reject the sensed request.

[0305] As previously mentioned, if the NEF receives a perception authorization response from the UDM indicating a refusal to authorize the perception request, it can send a rejection message to the AF to reject the perception request. Optionally, the rejection message can indicate the reason for rejecting the perception request. The reason for the rejection can be obtained from the perception authorization response from the UDM or determined by the NEF itself, and this application does not limit this.

[0306] One possible implementation is that the NEF can directly forward the perception authorization response received from the UDM to the AF, that is, the above-mentioned perception authorization response and rejection message can be the same message. Another possible implementation is that the NEF can generate a rejection message based on the perception authorization response received from the UDM, that is, the above-mentioned perception authorization response and rejection message can be different messages. In step 505, the SF determines whether the terminal is allowed to be perceived.

[0307] In the embodiments of this application, the target service requirements are related to the perception permission of the terminal, including: the target service requirements are obtained when it is determined that the terminal is allowed to be perceived, and / or, the target service requirements are determined according to the perception permission of the terminal. This embodiment mainly provides a processing flow for obtaining target service requirements when it is determined that the terminal is allowed to be perceived.

[0308] After receiving the perception request, the SF can first determine whether the terminal is allowed or not allowed to be perceived (that is, whether the terminal is allowed to be perceived), and then obtain the target service requirements when the terminal is allowed to be perceived.

[0309] Whether the terminal is allowed or not allowed to be perceived can be determined according to the perception permission subscribed by the terminal and / or the perception notification feedback of the terminal. The perception permission subscribed by the terminal has been described in detail in step 502 above, and reference can be made to the relevant content above, which will not be elaborated here.

[0310] One possible implementation is that the SF determines whether the terminal is allowed or not allowed to be perceived according to the perception permission subscribed by the terminal. If whether the terminal is allowed to be perceived does not need to be determined in combination with the response of the terminal (such as the perception notification feedback described in this article), for example, the perception permission subscribed by the terminal is not allowed to be perceived, or is allowed to be perceived, or is allowed to be perceived and needs to notify the terminal but does not require the terminal to reply, then it can be directly determined whether the terminal is allowed to be perceived. The perception permission subscribed by the terminal can be obtained from the UDM or pre-configured in the SF, and this application does not limit this.

[0311] It can be understood that if step 502 above has been executed, the UDM can determine whether the terminal is allowed to be perceived according to the perception permission subscribed by the terminal, and step 505 does not have to be executed.

[0312] In addition, if the perception permissions subscribed by the terminal include at least one type of perception permission corresponding to at least one area, the SF can obtain the location of the terminal (for example, by initiating a positioning process for the terminal), and then determine the corresponding perception permission according to the area to which the location of the terminal belongs, and then determine whether the terminal is allowed to be perceived.

[0313] Exemplarily, the SF can trigger the RAN node to initiate a positioning process for the terminal. The RAN node can send a reference signal to obtain the measurement data of the terminal for the reference signal, such as relative time of arrival (RTOA), angle of arrival (AOA) of the reference signal, reference signal receiving power (RSRP), and so on. The RAN node can determine the location of the terminal based on the measurement data and report it to the SF. The specific implementation process of the positioning process for the terminal can refer to the existing technology and will not be elaborated in this article.

[0314] Another possible implementation is that the SF can determine whether the terminal is allowed to be perceived based on the perception notification feedback of the terminal.

[0315] The perception notification feedback can indicate that the terminal replies to agree to be perceived, or the terminal replies not to agree to be perceived, or the terminal does not reply. The SF can determine that the terminal is allowed to be perceived when the perception notification feedback indicates that the terminal replies to agree to be perceived; determine that the terminal is not allowed to be perceived when the terminal replies not to agree to be perceived, and when the terminal does not reply, the SF can combine preset rules (such as the perception permissions subscribed by the terminal) to determine whether the terminal is allowed to be perceived.

[0316] Another possible implementation is that the SF determines whether the terminal is allowed to be perceived based on the perception permissions subscribed by the terminal and the perception notification feedback of the terminal.

[0317] For example, the perception permissions subscribed by the terminal are that the terminal needs to be notified and is allowed to be perceived when the terminal replies to agree or does not reply, and the perception notification feedback of the terminal indicates that the terminal does not reply, then it can be determined that the terminal is allowed to be perceived.

[0318] For another example, the perception permissions subscribed by the terminal are that the terminal needs to be notified and is allowed to be perceived only when the terminal replies to agree, and the perception notification feedback of the terminal indicates that the terminal does not reply, then it can be determined that the terminal is not allowed to be perceived.

[0319] In some cases, although the perceived permission subscribed by the terminal is to allow being perceived and the terminal needs to be notified without requiring a response from the terminal, the terminal replies that it does not agree to be perceived. At this time, the perceived notification feedback of the terminal can be taken as the main consideration to determine that the terminal does not allow being perceived. In other words, the priority of the perceived notification feedback of the terminal is higher than the priority of the perceived permission subscribed by the terminal.

[0320] For the perceived permission subscribed by the terminal, please refer to the relevant description above and will not be elaborated here.

[0321] Optionally, the method further includes step 506: The SF obtains the perceived notification feedback of the terminal.

[0322] The SF can obtain the perceived notification feedback of the terminal by sending a perceived notification request. Among them, the perceived notification request is used to request the terminal to reply whether it agrees to be perceived. Optionally, step 506 specifically includes: The SF sends the perceived notification request, and the SF obtains the perceived notification feedback of the terminal from the response message of the perceived notification request.

[0323] The figure shows a possible implementation manner of step 506 from the perspective of device interaction. Exemplarily, step 506 specifically includes the following steps 5061 to 5064:

[0324] Step 5061, the SF sends a perceived notification request to the AMF.

[0325] Step 5062, the AMF forwards the perceived notification request to the terminal to obtain a reply from the terminal.

[0326] Step 5063, the AMF sends a response message of the perceived notification request to the SF, and the response message of the perceived notification request indicates that the terminal replies that it agrees to be perceived, the terminal replies that it does not agree to be perceived, or the terminal does not reply.

[0327] Step 5064, the SF obtains the perceived notification feedback according to the response message of the perceived notification request.

[0328] Exemplarily, the perceived notification request carries a perception request, or the perceived notification request carries the SUPI of the terminal, and one or more of the following: the ID of the AF, the requested service requirement, or the requested service type. Further, the perceived notification request is also used to instruct the AMF to reply with the perceived notification feedback.

[0329] The response message of the perceived notification request can be a response message to the perceived notification request and can be used to indicate the perceived notification feedback. A possible design is that the response message of the perceived notification request carries the perceived notification feedback.

[0330] It should be noted that the SF and the terminal can communicate through the transit of network elements such as AMF and RAN nodes. Therefore, the perception notification request can be forwarded to the terminal through the AMF and RAN nodes. The AMF can also indicate the perception notification feedback of the terminal through the response message of the perception notification request based on the content of the terminal's reply or the status of no reply. The SF can determine whether the terminal is allowed to be perceived based on the perception notification feedback.

[0331] It should also be noted that the terminal's perception notification feedback is used to indicate the terminal's reply content or whether it has replied, but does not mean that the terminal must make a feedback. The terminal's perception notification feedback can be understood as the AMF's response to the perception notification request, combined with whether the terminal replies or the content of the reply.

[0332] In summary, there are several possible situations in which a terminal allows being sensed:

[0333] 1) The sensing permission signed by the terminal is to allow sensing;

[0334] 2) The sensing permission signed by the terminal is to allow sensing, and the terminal needs to be notified but does not need to reply. The terminal does not reply;

[0335] 3) The terminal needs to be notified, and is allowed to be sensed when the terminal replies with consent or does not reply, and the terminal's perception notification feedback indicates that the terminal replies with consent to be sensed or the terminal's perception notification feedback indicates that the terminal has not replied;

[0336] 4) The terminal needs to be notified and is only allowed to be sensed if the terminal replies with consent, and the terminal's perception notification feedback indicates that the terminal replies with consent to be sensed;

[0337] 5) The terminal does not have the contracted perception authority, but the perception notification feedback of the terminal indicates that the terminal agrees to be fed back.

[0338] In contrast, there are several possible situations where the terminal is not allowed to be sensed:

[0339] 1) The sensing permission signed by the terminal is not allowed to be sensed;

[0340] 2) The terminal needs to be notified, and the terminal is allowed to be sensed when it replies to agree or does not reply, and the terminal's perception notification feedback indicates that the terminal replies that it does not agree to be sensed;

[0341] 3) The terminal needs to be notified and is allowed to be sensed only when the terminal replies with consent, and the terminal's perception notification feedback indicates that the terminal replies that it does not agree to be sensed or the terminal's perception notification feedback indicates that the terminal has not replied;

[0342] 4) The terminal does not have the contracted sensing authority, but the sensing notification feedback of the terminal indicates that the terminal replies that it does not agree to be sensed;

[0343] 5) The perceived permission subscribed by the terminal is to allow being perceived, and the terminal needs to be notified but no response from the terminal is required, but the terminal responds that it does not agree to be perceived.

[0344] The above has shown various possible implementation manners for determining whether the terminal allows being perceived in combination with various possible permissions and multiple examples. These examples are only shown for easy understanding and should not constitute any limitation to this application.

[0345] In addition, the perceived permission subscribed by the terminal can be pre - stored in the SF, or the SF can obtain it from the UDM.

[0346] Optionally, the method further includes: Step 507, the SF obtains the perceived permission subscribed by the terminal from the UDM.

[0347] If the SF determines, according to the received perception request, that the perception request is for a certain terminal, it can request the UDM to obtain the perceived permission subscribed by the terminal.

[0348] As described above, the perception request also carries the identifier of the AF. The SF can determine whether the perception request comes from an authoritative agency or a regulatory agency according to the identifier of the AF. Exemplarily, an AF list can be pre - stored in the SF, and the AF list contains the identifiers of the AFs corresponding to predefined agencies. The predefined agency can be understood in this way: the perception requests from the predefined agency must be executed without having to confirm whether the terminal allows being perceived. In other words, steps 508 to 510 can be skipped and not executed, and steps 511 to 512 can be directly executed. The predefined agency can be, for example, an authoritative agency or a regulatory agency. The SF determines whether the perception request comes from a predefined agency according to the agency list and the identifier of the AF carried in the perception request.

[0349] In addition, if the identifier of the terminal obtained by the SF from the perception request received from the NEF is an external identifier rather than the SUPI, the SF can also obtain the SUPI of the terminal in step 507.

[0350] If the SF determines in step 505 that the terminal allows being perceived, it can continue to execute some steps from step 508 to step 513; if the SF determines in step 505 that the terminal does not allow being perceived, it can execute step 513, and the SF sends a rejection message to the AF.

[0351] In step 508, the SF obtains the target service requirements.

[0352] A possible implementation manner of step 508 is as shown in step 508a: The SF determines the target service requirements.

[0353] In a possible design, service requirements can be pre-stored in the SF, and these service requirements can be referred to as default service requirements. When the terminal allows itself to be sensed, the SF can directly determine the target service requirements.

[0354] In another possible design, the service requirements of the request can be carried in the above sensing request. When the terminal allows itself to be sensed, the SF can determine the service requirements of the request as the target service requirements. Or rather, the SF can also define the default service requirements as the service requirements of the request without pre-configuring the default service requirements.

[0355] In yet another possible design, the target service requirements can be determined based on the time information of the sensing request and / or the location of the terminal. That is to say, the SF can determine the target service requirements corresponding to the time information of the sensing request and / or the location of the terminal.

[0356] As an example, the target service requirements can be determined based on the time information of the sensing request.

[0357] The time information of the sensing request can be used to indicate one or more of the following: the time when the AF initiates the sensing request, the time when the SF receives the sensing request, or the time for which the sensing is requested carried in the sensing request.

[0358] The SF can determine the time period based on this time information, and then determine the target service requirements.

[0359] For example, if the time indicated by the time information is the night rest time, such as 21:00 - 7:00, since the user is in a resting state and does not want their privacy to be exposed, the target service requirements can be determined as service requirements with a lower sensing accuracy.

[0360] Another example, the target service requirements can be determined based on the location of the terminal.

[0361] The location of the terminal can be obtained by the SF. Based on the location of the terminal, the target service requirements corresponding to this location can be determined.

[0362] For example, if the location of the terminal is at the user's home, the user may not want their privacy to be exposed, so the target service requirements can be determined as service requirements with a lower sensing accuracy.

[0363] Yet another example, the target service requirements can be determined based on the time information of the sensing request and the location of the terminal.

[0364] For example, if the time indicated by the time information is during the morning rush hour or the evening rush hour, such as 7:00 - 9:00, or 17:00 - 19:00, and the location of the terminal is on a road. Since there are many terminals on the road during the morning and evening rush hours, a high-sensing-accuracy sensing may involve the leakage of some privacy or sensitive information. Therefore, the target service requirement can be determined as a service requirement with a lower sensing accuracy.

[0365] In summary, it can be seen that by combining the time information of the sensing request and / or the location of the terminal, the exposure of user privacy can be effectively avoided, the leakage of sensitive information can be reduced, which can not only meet the security needs of the terminal, but also effectively and flexibly provide network opening capabilities.

[0366] In a possible implementation manner, the target service requirement corresponding to the time information of the sensing request and / or the location of the terminal can be defined by a mapping relationship, and when determining the target service requirement according to the time information of the sensing request and / or the location of the terminal, this mapping relationship can be combined for determination.

[0367] Optionally, the mapping relationship may include the corresponding relationship between at least one service requirement and at least one time period. For the convenience of distinction and description, it is denoted as the first mapping relationship hereinafter. Table IV shows an example of the first mapping relationship.

[0368] Table IV

[0369] Service requirement Time period Service requirement A Time period A Service requirement B Time period B …… ……

[0370] Optionally, the mapping relationship may include the corresponding relationship between at least one service requirement and at least one area. For the convenience of distinction and description, it is denoted as the second mapping relationship hereinafter.

[0371] Table V shows an example of the second mapping relationship.

[0372] Table V

[0373] Service requirement Area Service requirement 1 Area 1 Service requirement 2 Area 2 …… ……

[0374] Optionally, the mapping relationship may include the corresponding relationship between at least one service requirement and at least one combination of an area and a time period. For the convenience of distinction and description, it is denoted as the third mapping relationship hereinafter.

[0375] Table VI shows an example of the third mapping relationship.

[0376] Table VI

[0377] Service requirement Time period Area Service requirement 1 Time period A Area 1 Service requirement 2 Time period B Area 2 …… …… ……

[0378] It should be understood that the first mapping relationship to the third mapping relationship shown in conjunction with Tables IV to VI above are only shown for ease of understanding and should not impose any limitation on this application. The mapping relationship for determining the target service requirement described above may include one or more of the first mapping relationship, the second mapping relationship, or the third mapping relationship. In addition, this application does not limit the specific form of these mapping relationships. For example, it can be a table or other forms, such as an enumeration arrangement of different combination cases. This application does not make any limitation in this regard.

[0379] It can be understood that Service Requirement A and Service Requirement B in Table IV, and Service Requirement 1 and Service Requirement 2 in Tables V and VI can all be regarded as several examples of default service requirements. In other words, there can be one or multiple default service requirements, and this application does not make any limitation in this regard.

[0380] Corresponding to the mapping relationships listed above, a possible implementation for the SF to determine the target service requirement based on the time information of the sensing request is that the SF determines the target service requirement based on the time information of the sensing request and the first mapping relationship. That is, the SF can determine the target service requirement corresponding to the time information according to this first mapping relationship. For example, taking the time when the AF initiates the sensing request as an example, the SF can determine the corresponding target service requirement according to the time period to which this time belongs and the above first mapping relationship.

[0381] A possible implementation for the SF to determine the target service requirement based on the location of the terminal is that the SF determines the target service requirement based on the location of the terminal and the second mapping relationship. That is, the SF can determine the area to which the location of this terminal belongs among the at least one area, and then determine the target service requirement corresponding to this area according to the second mapping relationship.

[0382] A possible implementation for the SF to determine the target service requirement based on the time information of the sensing request and the location of the terminal is that the SF determines the target service requirement based on the time information of the sensing request, the location of the terminal, and the mapping relationship. That is, the SF can determine the area to which the location of this terminal belongs and the time period to which this time information belongs, and then determine the corresponding target service requirement according to the third mapping relationship.

[0383] Optionally, the method further includes: the SF obtains the mapping relationship for determining the target service requirement.

[0384] The mapping relationship for determining the target service requirement (for example, including one or more of the first mapping relationship, the second mapping relationship, or the third mapping relationship) can be configured in the SF or in the UDM. Correspondingly, in step 5071a, the SF can obtain this mapping relationship from the local or from the UDM.

[0385] A possible implementation for the SF to obtain the mapping relationship locally is that the mapping relationship can be manually stored in the memory of the SF, or it can also be pre-sent by the AF to the SF, and the SF stores the received mapping relationship in the memory. The SF obtaining the mapping relationship locally specifically may refer to obtaining the mapping relationship from the memory.

[0386] Several possible implementations for the SF to obtain the mapping relationship from the UDM are as follows: For example, when the UDM sends a perception authorization reply in step 5023a, it can carry the perception permission subscribed by the terminal and the mapping relationship. Then, in step 503, the NEF can send the perception permission subscribed by the terminal and the mapping relationship to the SF through a perception request. At this time, the SF can obtain the mapping relationship for determining the target service requirement through steps 5023a and 503. Another example is that in step 507, when the SF obtains the perception permission subscribed by the terminal from the UDM, it can also obtain the mapping relationship. At this time, the SF can obtain the mapping relationship for determining the target service requirement through step 507. Of course, the SF can also request the mapping relationship from the UDM through additional signaling, and this application does not limit this.

[0387] Another possible implementation of step 508 is as shown in step 508b: The SF obtains the target service requirement from the UDM.

[0388] Exemplarily, step 508b may specifically include the following steps 5081b to 5083b:

[0389] 5081b, the SF sends a service requirement request to the UDM.

[0390] 5082b, the UDM determines the target service requirement based on the service requirement request.

[0391] 5083b, the UDM sends the target service requirement to the SF.

[0392] In step 5081b, a possible situation is that the service requirement request can be sent to the data management function network element when the SF determines that the terminal is allowed to be sensed. In other words, the sending of the service requirement request can be triggered by the condition that the terminal is allowed to be sensed. The data management function network element can determine the target service requirement after receiving the service requirement request and send it to the SF. That is to say, the sending of the service requirement request can be used to implicitly indicate that the terminal is allowed to be sensed. When the data management function network element receives the service requirement request, it can default that the terminal is allowed to be sensed.

[0393] Another possible scenario is that the service requirement request can also be sent when the SF determines the result of whether the terminal allows to be sensed, and the service requirement request can indicate whether the terminal allows or does not allow to be sensed. In other words, regardless of whether the terminal allows to be sensed, the SF can send the service requirement request to the data management function network element. The data management function network element can first determine whether the terminal allows to be sensed according to the received service requirement request. When the terminal allows to be sensed, it determines and sends the target service requirement to the SF, and when the terminal does not allow to be sensed, it does not have to determine the target service requirement. That is to say, the data management function network element does not necessarily have to determine and send the target service requirement. In this embodiment, for the convenience of introducing the subsequent process, it is assumed that the service requirement request indicates that the terminal allows to be sensed, and the UDM can determine the target service requirement based on the service requirement request.

[0394] In step 5082b, the way for the UDM to determine the target service requirement is similar to the way for the SF to determine the target service requirement as exemplified above. The default service requirement can be determined as the target service requirement, or the requested service requirement can be determined as the target service requirement. If the UDM determines the default service requirement as the target service requirement, the default service requirement can be pre-stored in the UDM, or the requested service requirement can be defined as the default service requirement.

[0395] Optionally, the service requirement request carries time information and / or location information. Correspondingly, step 5082b can specifically include: the UDM determines the target service requirement according to the location information and / or time information.

[0396] Among them, the location information indicates the location of the terminal, and the location information can be carried in the service requirement request, for example. The time information can be used to indicate one or more of the following: the time when the AF initiates the sensing request, the time when the SF receives the sensing request, the time for requesting sensing carried in the sensing request, the time when the SF sends the service requirement request, or the time when the UDM receives the service requirement request. The time information (such as the time when the AF initiates the sensing request, the time when the SF receives the sensing request, the time for requesting sensing carried in the sensing request, or the time when the SF sends the service requirement request) can be carried in the service requirement request, or can be determined according to the time when the UDM receives the service requirement request.

[0397] The UDM can determine the target service requirement according to the location information, that is, the UDM can determine the target service requirement according to the location of the terminal. A possible implementation manner is that the UDM can determine the target service requirement according to the location of the terminal and the first mapping relationship. For the specific process of the UDM determining the target service requirement according to the location of the terminal, reference can be made to the relevant description of the SF determining the target service requirement according to the location of the terminal in step 508a above, which will not be elaborated here.

[0398] The UDM can also determine the target service requirement according to the time information. A possible implementation is that the UDM determines the target service requirement according to the time information and the second mapping relationship. For the specific process of the UDM determining the target service requirement according to the time information, refer to the relevant description of the SF determining the target service requirement according to the time information in step 508a above, which will not be elaborated here.

[0399] The UDM can also determine the target service requirement according to the location information and the time information. A possible implementation is that the UDM determines the target service requirement according to the location, time information of the terminal and the third mapping relationship. For the specific process of the UDM determining the target service requirement according to the location information and the time information, refer to the relevant description of the SF determining the target service requirement according to the location information and the time information in step 508a above, which will not be elaborated here.

[0400] In the implementation shown in step 508b, the UDM may be preconfigured locally with the above mapping relationship for determining the target service requirement. For example, this mapping relationship can be manually stored in the memory of the UDM, or can also be sent to the UDM by the AF in advance, and the UDM stores the received mapping relationship in the memory. Although not shown in the figure, it can be understood that the UDM can obtain this mapping relationship from the local memory.

[0401] In step 509, the SF sends a service requirement confirmation request to the AF, and this service requirement confirmation request is used to request to adopt the target service requirement.

[0402] The SF can send a service requirement confirmation request to the AF when the target service requirement is different from the requested service requirement. For example, the SF can compare the target service requirement with the requested service requirement after obtaining the target service requirement to determine whether the target service requirement is the same as the requested service requirement. Or, the SF can also directly judge according to the perception notification feedback after obtaining the perception notification feedback in step 5064 whether it is necessary to adjust the service requirement, such as downgrading or upgrading, that is, to determine that the target service requirement is different from the requested service requirement, and it is not necessarily to determine after obtaining the target service requirement by comparing with the requested service requirement.

[0403] Of course, if the SF determines that the target service requirement is the same as the requested service requirement, or if the SF determines that it is not necessary to adjust the requested service requirement, or if the SF directly determines the requested service requirement as the target service requirement, then steps 509 to 510 do not need to be executed, and steps 511 and 512 are directly executed.

[0404] The SF can carry the target service requirement in this service requirement confirmation request to request to adopt this target service requirement.

[0405] The SF may carry the target service requirement in the service requirement confirmation request. This service requirement request is used to indicate to the AF that the sensing process will be performed using a service requirement different from that in the sensing request, and is used to request the AF to confirm whether the target service requirement can or cannot be used to perform sensing.

[0406] A possible situation is that the level of the target service requirement is different from the level of the requested service requirement. For example, if the level of the target service requirement is lower than the level of the requested service requirement, in this case, the service requirement confirmation request can be understood as a request for the AF to confirm whether the service requirement for performing sensing can or cannot be downgraded. This service requirement confirmation request can also be called a downgrade confirmation request.

[0407] Another possible situation is that the level of the target service requirement is different from the level of the requested service requirement. For example, if the level of the target service requirement is higher than the level of the requested service requirement, in this case, the service requirement confirmation request can be understood as a request for the AF to confirm whether the service requirement for performing sensing can or cannot be upgraded. This service requirement confirmation request can also be called an upgrade confirmation request.

[0408] It should be noted that the level of the service requirement can be determined according to the values of the various indicators corresponding to the service requirement. The indicators corresponding to the service requirement can be included in the service requirement, or indicated by the service requirement, or can also be the indicators in the KPIs converted from the service requirement. This application does not make any restrictions on this.

[0409] Several examples where the level of the target service requirement is lower than the level of the requested service requirement are as follows: For example, in the indicators corresponding to the target service requirement, the sensing position accuracy is 1m, and in the indicators corresponding to the requested service requirement, the sensing position accuracy is 1mm. Since the accuracy of 1mm is higher than that of 1m, it can be considered that the level of the target service requirement is lower than the level of the requested service requirement. Another example is that in the indicators corresponding to the target service requirement, the sensing resolution is 5m, and in the indicators corresponding to the requested service requirement, the sensing resolution is 1m. Since the sensing resolution of 1m is higher than that of 5m, it can be considered that the level of the target service requirement is lower than the level of the requested service requirement. Another example is that in the indicators corresponding to the target service requirement, the maximum sensing service delay is 0.5ms, and in the indicators corresponding to the requested service requirement, the maximum sensing service delay is 0.2ms. Since the delay of 0.2ms is shorter than that of 0.5ms, it can be considered that the level of the target service requirement is lower than the level of the requested service requirement.

[0410] Several examples where the level of the target service requirement is higher than that of the requested service requirement are as follows: For example, among the metrics corresponding to the target service requirement, the perceived position accuracy is 1 mm, and among the metrics corresponding to the requested service requirement, the perceived position accuracy is 1 m. Since the accuracy of 1 mm is higher than that of 1 m, it can be considered that the level of this target service requirement is higher than that of the requested service requirement. Another example is that among the metrics corresponding to the target service requirement, the perceived resolution is 1 m, and among the metrics corresponding to the requested service requirement, the perceived resolution is 5 m. Since the perceived resolution of 1 m is higher than that of 5 m, it can be considered that the level of this target service requirement is higher than that of the requested service requirement. Another example is that among the metrics corresponding to the target service requirement, the maximum perceived service latency is 0.2 ms, and among the metrics corresponding to the requested service requirement, the maximum perceived service latency is 0.5 ms. Since the latency of 0.2 ms is shorter than that of 0.5 ms, it can be considered that the level of the target service requirement is higher than that of the requested service requirement.

[0411] Of course, the SF can also initiate the sensing process for the terminal based on the target service requirement without confirming with the AF whether it agrees to adopt the target service requirement when the target service requirement is different from the requested service requirement. For example, when the level of the target service requirement is higher than that of the requested service requirement, the sensing process for the terminal is initiated based on the target service requirement without confirming with the AF whether it agrees to adopt the target service requirement. In this case, the SF does not have to determine whether the target service requirement is the same as the requested service requirement. In other words, steps 508 to 510 are optional steps and do not necessarily have to be executed.

[0412] In step 510, the AF sends a service requirement confirmation reply to the SF, and this service requirement confirmation reply indicates whether it agrees or disagrees to adopt the target service requirement.

[0413] The AF can determine whether to agree to adopt the target service requirement by considering factors such as service requirements, and indicate whether to agree to adopt the target service requirement to the SF through the service requirement confirmation reply.

[0414] If the service requirement confirmation reply indicates agreement to adopt the target service requirement, steps 511 and 512 can be executed; if the service requirement confirmation reply indicates disagreement to adopt the target service requirement, step 513 can be executed.

[0415] In step 511, the SF initiates the sensing process for the terminal based on the target service requirement.

[0416] Exemplarily, step 511 can specifically include the following steps 5111 to 5112:

[0417] 5111, the SF determines the KPIs for sensing the terminal based on the target service requirement.

[0418] 5112, the SF initiates a sensing process for the terminal based on the KPI.

[0419] Among them, the target service requirement can be a KPI, or include a KPI, or can also include information for determining a KPI, such as an identifier or parameter corresponding to the KPI, etc. The KPI is used to describe the accuracy with which sensing data needs to be obtained. Exemplarily, the KPI can include one or more of the following indicators: confidence interval, sensing positioning accuracy (including vertical and horizontal), sensing speed accuracy (including vertical and horizontal), sensing resolution (including area and speed), maximum sensing service delay, or refresh rate. These indicators are only an example of the KPI, and the present application does not limit the specific indicators included in the KPI.

[0420] If the target service requirement is a KPI or includes a KPI, the SF can directly obtain the KPI for sensing the terminal based on the target service requirement, and then initiate a sensing process for the terminal.

[0421] If the target service requirement includes information for determining a KPI, the SF can convert the target service requirement into a KPI. In other words, one possible implementation for the SF to determine the KPI for sensing the terminal based on the target service requirement is to determine the target service requirement as the KPI for sensing the terminal, and another possible implementation is to convert the target service requirement into the KPI for sensing the terminal.

[0422] In one possible implementation, the target service requirement may include an identifier corresponding to the KPI, and the SF can convert the target service requirement into the KPI for sensing the terminal according to the identifier in the target service requirement. One possible implementation is that the SF pre-stores at least one correspondence between at least one identifier and at least one KPI, and each KPI can include one or more indicators. The SF can find the KPI corresponding to the identifier from the pre-stored correspondence according to the identifier included in the target service requirement.

[0423] In another possible implementation, the target service requirement may also include a parameter corresponding to the KPI, and the SF can convert the target service requirement into the KPI for sensing the terminal according to the parameter in the target service requirement. One possible implementation is that the SF pre-stores at least one correspondence between at least one set of parameters and at least one KPI, each set of parameters can include one or more parameters, and each KPI can include one or more indicators. The SF can find the KPI corresponding to the set of parameters from the pre-stored correspondence according to the set of parameters included in the target service requirement.

[0424] It can be transformed according to the correspondence between predefined service requirements and KPIs. For example, the target service requirement is a specific identifier, and the SF has a predefined KPI corresponding to the specific identifier. It can also be that the parameters in the sensing requirement are translated into the parameters of the KPI. For example, the parameters in the sensing requirement correspond one-to-one with the parameters of the KPI, and the SF determines the parameters in the sensing requirement as the corresponding KPI parameters respectively. The sensing requirement can also be equivalent to the KPI, that is, no translation by the SF is required.

[0425] After the SF determines the KPI, it can initiate a sensing process for the terminal based on this KPI.

[0426] The specific process by which the SF initiates a sensing process for the terminal can be that the SF selects specific sensing nodes (transmitter and receiver) and instructs the sensing nodes to send and receive sensing signals for this terminal using this KPI, and determines the sensing result after obtaining the sensing data.

[0427] Table VII below exemplarily shows six possible sensing modes, which are distinguished for the transmitter and receiver of the sensing signal respectively, specifically: the RAN node sends and receives by itself, the RAN node A sends and the RAN node B receives, the RAN node sends and the terminal receives, the terminal sends and the RAN node receives, the terminal sends and receives by itself, and the terminal A sends and the terminal B receives. It can be seen that the transmitter can be a terminal or a RAN node; the receiver can be a terminal or a RAN node.

[0428] Table VII

[0429]

[0430] In this embodiment, the SF can initiate a sensing process for the terminal by adopting one of the sensing modes. For example, the transmitter and receiver are determined according to the selected sensing mode, and then the above KPI is indicated to the transmitter and receiver.

[0431] For the specific process of the SF initiating a sensing process for the terminal, reference can be made to the existing technology. For the sake of brevity, it will not be described in detail.

[0432] In step 512, the SF sends the sensing result to the AF.

[0433] After completing the sensing process for this terminal, the SF can send this sensing result to the AF through network elements such as the NEF or UPF.

[0434] In step 513, the SF sends a rejection message, which is used to indicate the rejection of the sensing request.

[0435] If the SF determines in step 505 that the terminal is not allowed to be sensed, or receives a service requirement confirmation reply in step 510 indicating disagreement with the adoption of the target service requirement, it can send a rejection message to the AF through the NEF to reject the above sensing request.

[0436] Optionally, the rejection message indicates the reason for rejecting the sensing request. Exemplarily, the reason for rejecting the sensing request can be that the terminal is not allowed to be sensed, or the AF disagrees with the adoption of the target service requirement, etc., and will not list them one by one.

[0437] A possible implementation is to indicate different reasons through different reason values. Then, the rejection message carries the reason value, and the reason value is used to indicate the reason for rejecting the sensing request.

[0438] In addition, since in the converged architecture, the UDM and the SF can interact with the AF through the same NEF, the sending of the rejection message in step 504 above and the sending of the rejection message in step 513 can be the same sending step for the NEF.

[0439] Based on the above solution, when the SF receives a sensing request, it can first determine whether the terminal is allowed to be sensed, and then obtain the target service requirement for determining the KPI for sensing the terminal in the case of permission, so that the sensing process initiated for the terminal is adapted to the sensing permission of the terminal, rather than blindly directly determining the KPI for sensing the terminal according to the service requirements requested by the AF network element or the AS, etc. Or rather, the present application can obtain the target service requirement in terms of the terminal granularity. Therefore, considering the security requirements of different terminals, it can respond flexibly according to the security requirements of different terminals, rather than blindly according to the sensing request of the AF, and perform sensing without distinguishing terminals. In addition, by pre-configuring the correspondence between service requirements and regions, time periods, service types, etc. for each terminal, the SF can determine the target service requirement according to factors such as the terminal requested to be sensed, the location of the terminal, the time of the requested sensing, the service type of the request, etc., so that the network can use different service requirements to sense the terminal in different regions, different time periods, and different service types, thus providing a more flexible network opening capability.

[0440] As described above in conjunction with Figure 5 shows a possible process of the method provided by the present application, Figure 5 each step shown is only an example and does not mean that it must be executed Figure 5All steps therein, for example, step 503 and step 504 can be alternatively executed, step 511 to 512 and step 513 can be alternatively executed, step 507a and step 507b can be alternatively executed, and so on. The sequence numbers of the steps do not mean the order of execution, and the execution order of each step should be determined according to its function and internal logic.

[0441] Figure 6 is another schematic flowchart of the perception method provided by the embodiments of the present application. Different from Figure 5 the method 500 shown, Figure 6 the method 600 shown provides another processing logic for obtaining target service requirements. The steps different from those in method 500, the steps the same as those in method 500, and the descriptions of the same terms will be described in detail below. For the relevant descriptions of the same steps and terms in method 500, reference can be made to the above descriptions of method 500 and will not be repeated here.

[0442] As Figure 6 shown, the method 600 may include steps 601 to 611. Each step in the method 600 will be described in detail below.

[0443] In step 601, the AF sends a perception request to the NEF, and the perception request is used to request to perceive the terminal.

[0444] In step 602, the NEF obtains authorization for the perception request from the UDM.

[0445] Optionally, step 602 specifically includes the following steps 6021 to 6023:

[0446] Step 6021, the NEF sends a perception authorization request to the UDM, and the perception authorization request is used to request the UDM to authorize the perception request.

[0447] Step 6022, the UDM determines whether the terminal is allowed or not allowed to be perceived according to the perception permissions subscribed by the terminal.

[0448] Step 6023, the UDM sends a perception authorization reply to the NEF, and the perception authorization reply is used to indicate authorization or rejection of the perception request.

[0449] In step 603, the NEF sends a perception request to the SF.

[0450] In step 604, the NEF sends a rejection message to the AF, and the rejection message is used to reject the perception request.

[0451] In step 605, the SF obtains the perception permissions subscribed by the terminal.

[0452] The specific processes of steps 601 to 605 are the same as those of steps 501 to 504 in method 500, and the specific process of step 506. For the relevant descriptions of steps 501 to 504 and step 507 in method 500 above, please refer to the above text and will not be elaborated here.

[0453] In step 606, the SF obtains the perception notification feedback of the terminal. The SF can obtain the perception notification feedback of the terminal by sending a perception notification request. The perception notification request is used to request the terminal to reply whether it agrees to be perceived. Optionally, step 606 specifically includes: the SF sends a perception notification request; the SF obtains the perception notification feedback of the terminal according to the response message of the perception notification request.

[0454] A possible implementation of step 606 is shown from the perspective of device interaction in the figure. Exemplarily and optionally, step 606 specifically includes the following steps 6061 to 6064:

[0455] Step 6061, the SF sends a perception notification request to the AMF.

[0456] Step 6062, the AMF forwards the perception notification request to the terminal to request a reply from the terminal.

[0457] Step 6063, the SF receives the response message of the perception notification request. The response message of the perception notification request indicates that the terminal replies to agree to be perceived, the terminal replies not to be perceived, or the terminal does not reply.

[0458] Step 6064, the SF obtains the perception notification feedback according to the response message of the perception notification request.

[0459] The specific process of step 606 is similar to that of step 506 in method 500. For the relevant description, please refer to step 506 of method 500. Different from method 500, the SF can obtain the target service requirements without determining whether the terminal allows to be perceived. Therefore, the SF does not need to first determine whether the terminal allows to be perceived, but can directly execute step 607.

[0460] In step 607, the SF obtains the target service requirements.

[0461] In the embodiments of the present application, the target service requirements are related to the perception permission of the terminal, including: the target service requirements are obtained when it is determined that the terminal allows to be perceived, and / or, the target service requirements are determined according to the perception permission of the terminal. This embodiment mainly provides a processing flow for determining the target service requirements according to the perception permission of the terminal.

[0462] In other words, in this embodiment, the SF does not need to obtain the target service requirements when determining whether the terminal is allowed to be sensed. Specifically, the target service requirements are obtained according to the sensing notification feedback of the terminal and / or the sensing permissions subscribed by the terminal, etc.

[0463] A possible implementation of step 607 is shown in step 607a: The SF determines the target service requirements.

[0464] The SF can determine the target service requirements according to the sensing permissions subscribed by the terminal and / or the sensing notification feedback of the terminal. That is to say, the SF can determine the target service requirements corresponding to the sensing permissions subscribed by the terminal and / or the sensing notification feedback.

[0465] In a possible implementation, the target service requirements corresponding to the sensing permissions subscribed by the terminal and / or the sensing notification feedback of the terminal can be defined by a mapping relationship. This mapping relationship indicates the corresponding relationship between at least one service requirement and at least one combination of the sensing permissions subscribed by the terminal and the sensing notification feedback of the terminal. The SF can determine the target service requirements according to the above mapping relationship and one or more of the sensing permissions subscribed by the terminal or the sensing notification feedback of the terminal.

[0466] Optionally, this mapping relationship includes at least one service requirement and at least one combination of the sensing permissions subscribed by the terminal and the sensing notification feedback. For the convenience of distinction and description, it is denoted as the fourth mapping relationship hereinafter.

[0467] For the convenience of understanding, Table VIII shows an example of this fourth mapping relationship.

[0468] Table VIII

[0469]

[0470] For each terminal, this fourth mapping relationship can include one set of the multiple sets of corresponding relationships shown in Table VIII.

[0471] It can be seen that in the fourth mapping relationship shown in Table VIII, in the two sets of corresponding relationships corresponding to indexes 1 and 2, the service requirements correspond to the sensing permissions subscribed by the terminal. Therefore, the target service requirements can be determined according to the sensing permissions subscribed by the terminal without combining the sensing notification feedback. Although not shown in the figure, it can be understood that the fourth mapping relationship can also include the corresponding relationship between the sensing notification feedback and the service requirements. In this case, the target service requirements can also be determined according to the sensing notification feedback of the terminal without combining the sensing permissions subscribed by the terminal.

[0472] Further, the SF may further combine the location and / or time information of the terminal to determine the target service requirements. In other words, the above mapping relationship includes the corresponding relationship between at least one service requirement and at least one combination of the following one or more items: the sensing permissions subscribed by the terminal, the sensing notification feedback of the terminal, the area, or the time period.

[0473] Optionally, the mapping relationship includes at least one combination of at least one service requirement and the sensing permissions subscribed by the terminal, the sensing notification feedback, and the area. For the convenience of distinction and description, it is denoted as the fifth mapping relationship hereinafter.

[0474] For the convenience of understanding, Table IX shows an example of the fifth mapping relationship.

[0475] Table IX

[0476]

[0477]

[0478] For each terminal, the fifth mapping relationship may include one or more groups of the corresponding relationships shown in Table IX.

[0479] Optionally, the mapping relationship includes at least one combination of at least one service requirement and the sensing permissions subscribed by the terminal, the sensing notification feedback, and the time period. For the convenience of distinction and description, it is denoted as the sixth mapping relationship hereinafter.

[0480] For the convenience of understanding, Table X shows an example of the sixth mapping relationship.

[0481] Table X

[0482]

[0483] For each terminal, the sixth mapping relationship may include one or more groups of the corresponding relationships shown in Table X.

[0484] Optionally, the mapping relationship includes at least one combination of at least one service requirement and the sensing permissions subscribed by the terminal, the sensing notification feedback, the time period, and the area. For the convenience of distinction and description, it is denoted as the seventh mapping relationship hereinafter.

[0485] For the convenience of understanding, Table XI shows an example of the seventh mapping relationship.

[0486] Table XI

[0487]

[0488] For each terminal, the seventh mapping relationship may include one or more groups of the corresponding relationships shown in Table XI.

[0489] Furthermore, the above fourth mapping relationship, fifth mapping relationship, sixth mapping relationship, and seventh mapping relationship can also correspond to service types. That is to say, the mapping relationships shown in Table VIII, Table IX, Table X, and Table XI can be mapping relationships corresponding to a certain service type. The fourth mapping relationship, fifth mapping relationship, sixth mapping relationship, and seventh mapping relationship can also include mapping relationships corresponding to one or more other service types. For the sake of simplicity, no examples are listed here. It can be understood that if the above mapping relationships correspond to service types, the SF can determine the mapping relationship according to the service type of the request indicated by the sensing request, and then determine the target service requirements according to the mapping relationship.

[0490] In addition, both Service Requirement 1 and Service Requirement 2 shown in Table VIII, Table IX, Table X, and Table XI can be understood as default service requirements. In this embodiment, the default service requirements can also be divided into multiple levels. For example, the level of Service Requirement 1 is higher than the level of Service Requirement 2. The SF can select one of the service requirements as the target service requirement according to the sensing permission and sensing notification feedback subscribed by the terminal. The specific content of the level of the service requirement can refer to the relevant description in step 509 of the above method 500, and will not be elaborated here.

[0491] Taking the default service requirements being divided into two levels (i.e., including Service Requirement 1 and Service Requirement 2) as an example. One possible design is that both Service Requirement 1 and Service Requirement 2 can be pre-configured. Another possible design is that Service Requirement 1 is the requested service requirement, or rather, Service Requirement 1 does not need to be pre-configured, and Service Requirement 2 is pre-configured. At this time, Service Requirement 1 can also be called the requested service requirement.

[0492] Service Requirement 1 and Service Requirement 2 in the table are only examples. The default service requirements can also be divided into more levels, or not divided into levels. At this time, the fourth mapping relationship, fifth mapping relationship, sixth mapping relationship, and seventh mapping relationship respectively shown in Table VIII, Table IX, Table X, and Table XI can also be adjusted accordingly. For the sake of simplicity, no examples are listed here.

[0493] It can be understood that not distinguishing the levels of the default service requirements can make the processing on the network side simpler. Defining multiple levels for the default service requirements can enable the network side to flexibly select service requirements according to different sensing notification feedbacks of the terminal, so as to balance the security requirements of the terminal and the service requirements of the AF and provide a better user experience.

[0494] It should also be noted that in method 600, since the SF does not pre-determine whether the terminal allows to be sensed, and the terminal may reply that it does not agree to be sensed, that is, the terminal does not allow to be sensed. Therefore, in the fourth mapping relationship, the fifth mapping relationship, the sixth mapping relationship, and the seventh mapping relationship shown in Table VIII, Table IX, Table X, and Table XI above, the service requirements corresponding to some combinations of the sensing permissions subscribed by the terminal and the sensing notification feedback can be defined as rejecting the sensing request, or set to a predefined value (such as "0" or "null value (NULL)") to indicate rejecting the sensing request. These combinations may include: the sensing permission subscribed by the terminal is "not allowed to be sensed", and the sensing notification feedback is "N / A"; the sensing permission subscribed by the terminal is "need to notify the terminal, allow to be sensed when the terminal replies yes or does not reply; need to notify the terminal, do not allow to be sensed when the terminal replies no", and the sensing notification feedback is "reply not to be sensed"; the sensing permission subscribed by the terminal is "need to notify the terminal, do not allow to be sensed when the terminal replies no or does not reply; need to notify the terminal, allow to be sensed when the terminal replies yes", and the sensing notification feedback is "reply not to be sensed".

[0495] Next, the process of the SF determining the target service requirements will be illustrated by way of example in combination with the foregoing fourth mapping relationship, fifth mapping relationship, and sixth mapping relationship respectively.

[0496] In one implementation, the SF determines the target service requirements based on the sensing notification feedback of the terminal, the sensing permissions subscribed by the terminal, and the fourth mapping relationship.

[0497] Taking the fourth mapping relationship shown in Table VIII as an example.

[0498] For example, if the sensing permission subscribed by the terminal is not allowed to be sensed, the SF can determine to reject the sensing request.

[0499] For another example, the sensing permission subscribed by the terminal is: need to notify the terminal, allow to be sensed when the terminal replies yes or does not reply. If the sensing notification feedback of the terminal indicates that the terminal does not reply, the SF can determine that the target service requirement is service requirement 2.

[0500] For still another example, the sensing permission subscribed by the terminal is: need to notify the terminal, allow to be sensed only when the terminal replies yes. If the sensing notification feedback of the terminal is that the terminal replies yes to be sensed, the SF can determine that the target service requirement is service requirement 1.

[0501] In another implementation, the SF determines the target service requirements based on the sensing notification feedback of the terminal, the sensing permissions subscribed by the terminal, the location of the terminal, and the fifth mapping relationship. Among them, the location of the terminal can be obtained by initiating a positioning process for the terminal.

[0502] Take the fifth mapping relationship shown in Table 9 as an example.

[0503] For example, if the location of the terminal belongs to Region 2, the perceived permission subscribed by the terminal in Region 2 is to allow being perceived, and the SF can determine that the target service requirement is Service Requirement 1.

[0504] For another example, if the location of the terminal belongs to Region 4, the perceived permission subscribed by the terminal in Region 4 is: it is necessary to notify the terminal and allow being perceived when the terminal replies consent or does not reply. If the perceived notification feedback of the terminal is that the terminal does not reply, the SF can determine that the target service requirement is Service Requirement 2.

[0505] In another implementation, the SF determines the target service requirement according to the perceived notification feedback of the terminal, the perceived permission subscribed by the terminal, the time information of the perception request, and the sixth mapping relationship. Among them, the location of the terminal can be obtained by initiating a positioning process for the terminal. The time information of the perception request can be used to indicate: the time when the AF initiates the perception request or the time when the SF receives the perception request.

[0506] Take the sixth mapping relationship shown in Table 10 as an example.

[0507] For example, if the time when the SF receives the perception request belongs to Time Period C, the perceived permission subscribed by the terminal within Time Period C is to allow being perceived, it is necessary to notify the terminal but no reply from the terminal is required, and the SF can determine that the target service requirement is Service Requirement 1.

[0508] For another example, if the time when the SF receives the perception request belongs to Time Period E, the perceived permission subscribed by the terminal within Time Period E is: it is necessary to notify the terminal and allow being perceived only when the terminal replies consent. If the terminal does not reply, the SF can determine that the target service requirement is to reject the perception request.

[0509] Take the seventh mapping relationship described in Table 11 as an example.

[0510] For example, if the time when the SF receives the perception request belongs to Time Period C and the location of the terminal belongs to Region 3, the perceived permission subscribed by the terminal corresponding to Time Period C and Region 3 is to allow being perceived, it is necessary to notify the terminal but no reply from the terminal is required, and the SF can determine that the target service requirement is Service Requirement 1.

[0511] For another example, if the time when the SF receives the perception request belongs to Time Period E and the location of the terminal belongs to Region 5, the perceived permission subscribed by the terminal corresponding to Time Period E and Region 5 is: it is necessary to notify the terminal and allow being perceived only when the terminal replies consent. If the terminal does not reply, the SF can determine that the target service requirement is to reject the perception request.

[0512] The example of the process in which the SF determines the target service requirements in combination with the fourth mapping relationship, the fifth mapping relationship, the sixth mapping relationship, and the seventh mapping relationship shown in Table VIII, Table IX, Table X, and Table XI above is only an example and should not impose any limitation on this application.

[0513] Optionally, the method further includes: the SF obtains a mapping relationship for determining the target service requirements.

[0514] This mapping relationship can be configured in the SF or pre-configured in the UDM. Correspondingly, the SF can obtain this mapping relationship locally or from the UDM.

[0515] A possible implementation for the SF to obtain this mapping relationship locally is that this mapping relationship can be manually stored in the memory of the SF, or it can also be pre-sent by the AF to the SF in advance, and the SF stores the received mapping relationship in the memory. That the SF obtains this mapping relationship locally specifically may refer to obtaining this mapping relationship from the memory.

[0516] Several possible implementations for the SF to obtain this mapping relationship from the UDM are as follows: For example, when the UDM sends a sensing authorization reply in step 6023a, it can carry the sensing permissions subscribed by the terminal and this mapping relationship. Then, in step 603, the NEF can send the sensing permissions subscribed by the terminal and this mapping relationship to the SF through the sensing request. At this time, the SF can obtain the mapping relationship for determining the target service requirements through steps 6023a and 603. Another example is that when the SF obtains the sensing permissions subscribed by the terminal from the UDM in step 606, it can also obtain this mapping relationship. At this time, the SF can obtain the mapping relationship for determining the target service requirements through step 605. Of course, the SF can also request this mapping relationship from the UDM through additional signaling, and this application does not make any limitation on this.

[0517] Another possible implementation of step 607 is shown in step 607b, where the SF requests the target service requirements from the UDM.

[0518] Exemplarily, step 607b may specifically include the following steps 6071b to 6073b:

[0519] 6071b, the SF sends a service requirements request to the UDM, and the terminal's sensing notification feedback is carried in this service requirements request.

[0520] 6072b, the UDM determines the target service requirements based on this service requirements request.

[0521] 6073b, the UDM sends this target service requirements to the SF.

[0522] Different from step 507b in method 500, the service requirement request sent by the SF to the UDM carries the perception notification feedback of the terminal. In other words, this service requirement request is not necessarily sent when the terminal permits to be perceived, and this service requirement request is not used to indicate that the terminal permits to be perceived. The UDM can determine the target service requirement based on the perception notification feedback of this terminal, the perception permission subscribed by this terminal, and the mapping relationship.

[0523] The specific process for the UDM to determine the target service requirement based on the perception notification feedback of this terminal, the perception permission subscribed by this terminal, and the mapping relationship is similar to the specific process for the SF to determine the target service requirement based on the perception notification feedback of this terminal, the perception permission subscribed by this terminal, and the mapping relationship. For example, it can be determined based on the perception notification feedback of the terminal, the perception permission subscribed by the terminal, and the fourth mapping relationship, or, based on the perception notification feedback of the terminal, the perception permission subscribed by the terminal, the location of the terminal, and the fifth mapping relationship, or, based on the perception notification feedback of the terminal, the perception permission subscribed by the terminal, the time information, and the sixth mapping relationship. This time information can be the time information of the perception request, which can be used to indicate the time when the AF initiates the perception request or the time when the SF receives this perception request, or it can also be the time information of the service requirement request, which can be used to indicate the time when the SF sends the service requirement request or the time when the UDM receives this service requirement request, etc.

[0524] For more specific content regarding the UDM's determination of the target service requirement based on the perception notification feedback of this terminal, the perception permission subscribed by this terminal, and the mapping relationship, reference can be made to the relevant description in step 607a above, and details will not be elaborated here.

[0525] Of course, the UDM can also determine whether the terminal permits or does not permit to be perceived based on the perception permission subscribed by this terminal and / or the perception notification feedback, and then determine the target service requirement when the terminal permits to be perceived. In this case, the UDM can adopt a similar method as in step 607a to determine the target service requirement based on the perception permission subscribed by the terminal and the perception notification feedback, and can also combine the time information and / or location information to determine the target service requirement; it can also adopt the method in step 5082b of method 500 to determine the default service requirement as the target service requirement, or, determine the requested service requirement as the target service requirement, or, determine the target service requirement based on the time information and / or location information. This application does not make any limitations in this regard.

[0526] It can be understood that if the target service requirement obtained by the SF is to reject the perception request, then steps 608 to 611 can be skipped, and step 612 can be directly executed, where the SF sends a rejection message.

[0527] In step 608, the SF sends a service requirement confirmation request to the AF, and this service requirement confirmation request is used to request the adoption of the target service requirement.

[0528] In step 609, the AF sends a service requirement confirmation reply to the SF, and this service requirement confirmation reply indicates agreement or disagreement to adopt the target service requirement.

[0529] In step 610, the SF initiates a sensing process for the terminal based on this target service requirement.

[0530] In step 611, the SF sends the sensing result to the AF.

[0531] In step 612, the SF sends a rejection message to the AF, and this rejection message is used to indicate the rejection of the sensing request.

[0532] For the specific processes of steps 608 to 612, reference may be made to the relevant descriptions of steps 509 to 513 in the above method 500, which will not be elaborated herein.

[0533] It can be understood that the SF can also initiate a sensing process for the terminal based on the target service requirement when the target service requirement is different from the requested service requirement, without confirming with the AF whether it agrees to adopt the target service requirement. In this case, the SF does not have to determine whether the target service requirement is the same as the requested service requirement. In other words, steps 609 to 610 are optional steps and do not necessarily have to be executed.

[0534] Based on the above solution, when the SF receives a sensing request, it can first obtain the sensing notification feedback of the terminal, and then obtain the target service requirement of the KPI for sensing this terminal, so that the sensing process initiated for the terminal is adapted to the sensing permission of the terminal, rather than blindly directly determining the KPI for sensing the terminal according to the service requirements requested by the AF network element or the AS, etc. Or rather, this application can be related to the sensing permission of the terminal, and the target service requirement is obtained with the terminal as the granularity. Therefore, the network side considers the security requirements of different terminals and flexibly responds to the sensing request according to the security requirements of different terminals, rather than blindly performing sensing according to the sensing request of the AF without distinguishing terminals. In addition, by pre-configuring the correspondence between the service requirement and the region, time period, service type, etc. for each terminal, the SF can determine the target service requirement according to factors such as the terminal to be requested for sensing, the location of this terminal, the time of requesting sensing, the service type of the request, etc., so that the network can use different service requirements to sense the terminal in different regions, different time periods, and different service types, thus providing a more flexible network opening capability.

[0535] As described above in conjunction with Figure 6 shows a possible process of the method provided by this application.Figure 5 The various steps shown are only examples and do not mean that all steps must be executed. Figure 6 For example, step 603 and step 604 can be executed alternatively, step 610 to 611 and step 612 can be executed alternatively, step 607a and step 607b can be executed alternatively, and so on. The sequence numbers of the steps do not mean the order of execution either. The execution order of each step should be determined by its function and internal logic.

[0536] As can be seen from the method described above in combination with Figure 5 and Figure 6 the target service requirements can be determined when the terminal is allowed to be sensed, or can be determined according to the sensing permissions subscribed by the terminal and the sensing notification feedback of the terminal. Whether the terminal is allowed or not to be sensed is exactly determined according to the sensing permissions subscribed by the terminal and / or the sensing notification feedback, and whether the terminal is allowed or not to be sensed can also be indicated by the sensing permissions of the terminal. Therefore, generally speaking, the target service requirements are related to the sensing permissions of the terminal.

[0537] As described above in combination with Figure 5 and Figure 6 in the process shown, the interaction among AF, NEF, UDM, SF and the terminal, etc. is taken as an example to describe the sensing method provided by this application, but this should not impose any limitation on this application. In another possible architecture, the network side may include a sensing server (or called a sensing service platform), and the terminal may install a sensing client. The sensing server can be understood as a sensing service platform provided by the network and located at the upper layer of the protocol stack, and the sensing client can be understood as a sensing service platform located at the upper layer of the protocol stack in the UE. User plane interaction can be achieved between the sensing server and the sensing client. The sensing server can be regarded as a functional network element for docking external applications (such as AF or AS), and user plane interaction can also be achieved between the sensing server and AS. Considering that the network can provide multiple sensing functions, and the sensing requests of applications may involve multiple or multiple sensing functions provided by the network, therefore, in order to avoid external applications (such as AF or AS) needing to split their sensing requests into multiple or multiple sensing functions provided by the network for requests, the network can use the sensing server to proxy the sensing requests of applications and the multiple or multiple sensing functions provided by the network. Specifically, the sensing server is used to receive the sensing requirements of external applications (AF or AS), and further interact with the network and the UE according to the sensing requirements and feedback the sensing results.

[0538] In the embodiments of this application, the sensing server can be used to implement Figure 5 or Figure 6 the partial functions of SF in the process shown in Figure 5 or Figure 6The functions of the terminal in the process shown. For ease of understanding, the following will be described in conjunction with Figure 7 and Figure 8 .

[0539] Figure 7 is another schematic flowchart of the sensing method provided by the embodiments of the present application. Figure 7 Similar to Figure 5 shown in the processing flow of method 500, the same or similar steps in method 500, as well as the descriptions of the same terms, can refer to the relevant descriptions in method 500 above and will not be repeated.

[0540] As Figure 7 shown, the method 700 may include steps 701 to 713. The following will detail each step in method 700.

[0541] In step 701, the AS sends a first sensing request to the sensing server, and this first sensing request is used to request to sense the terminal.

[0542] Since the AS can interact with the sensing server on the user plane, this first sensing request is a user plane message. Exemplarily, this first sensing request carries the external identifier of the terminal, and one or more of the following: the identifier of the AS, the requested service requirements, or the requested service type.

[0543] The process of the AS sending the first sensing request to the sensing server is similar to the process in step 501 of method 500 above where the AF sends a sensing request to the NEF, and reference can be made to the relevant description in step 501 of method 500 above and will not be repeated.

[0544] In step 702, the sensing server obtains authorization for the sensing request from the UDM.

[0545] Exemplarily, step 702 may include the following steps 7021 to 7023:

[0546] Step 7021, the sensing server sends a sensing authorization request to the UDM, and this sensing authorization request is used to request the UDM to authorize this first sensing request, or to request the UDM to perform an authorization check on this first sensing request.

[0547] Step 7022, the UDM determines whether the terminal is allowed or not allowed to be sensed according to the sensing permissions subscribed by the terminal.

[0548] Step 7023, the UDM sends a sensing authorization reply to the sensing server, and this sensing authorization reply is used to indicate authorization or rejection of this first sensing request.

[0549] If the sensing authorization reply indicates a refusal to authorize the first sensing request, step 703 may be executed; if the sensing authorization reply indicates authorization of the first sensing request, some steps among steps 704 to 713 may be executed.

[0550] Optionally, when the sensing authorization reply indicates authorization of the first sensing request, the sensing authorization reply may further carry one or more of the following: the SUPI of the terminal, the sensing permissions subscribed by the terminal, or the mapping relationship for determining the target service requirements.

[0551] Optionally, when the sensing authorization reply indicates a refusal to authorize the first sensing request, the sensing authorization reply may further indicate the reason for the refusal.

[0552] For a more detailed description of step 702, reference may be made to the relevant content in step 502 of method 500, which will not be elaborated here.

[0553] In step 703, the sensing server sends a rejection message to the AS.

[0554] The specific process of the sensing server sending a rejection message to the AS is similar to the specific process of the NEF sending a rejection message to the AF in step 503 of method 500. Reference may be made to the relevant description in step 503 of method 500, which will not be elaborated here.

[0555] In step 704, the sensing server determines whether the terminal permits being sensed.

[0556] The specific process of the sensing server determining whether the terminal permits or does not permit being sensed is similar to the specific process of step 505 of method 500. Reference may be made to the relevant description in step 505 of method 500 above, which will not be elaborated here.

[0557] Optionally, the method further includes step 705: the sensing server obtains the sensing notification feedback of the terminal.

[0558] The sensing server may obtain the sensing notification feedback by sending a sensing notification request. The sensing notification request is used to request the terminal to reply whether it agrees to be sensed. Optionally, step 705 specifically includes: the sensing server sends a sensing notification request; the sensing server obtains the sensing notification feedback according to the response message of the sensing notification request.

[0559] Different from methods 500 and 600, the sensing server can perform user-plane interaction with the sensing client installed on the terminal without relaying through the AMF and RAN nodes. Therefore, the sensing server can send the sensing notification request to the sensing client and receive the response message of the sensing notification request from the sensing client.

[0560] A possible implementation of step 705 is shown from the perspective of device interaction in the figure. Exemplarily, step 705 includes the following steps 7051 to 7054:

[0561] Step 7051, the sensing server sends a sensing notification request to the sensing client.

[0562] Step 7052, the sensing client sends a response message to the sensing server for the sensing notification request, and the response message for the sensing notification request indicates that the terminal replies to agree to be sensed, the terminal replies to disagree to be sensed, or the terminal does not reply.

[0563] Step 7053, the sensing server obtains a sensing notification feedback according to the response message for the sensing notification request.

[0564] Exemplarily, after receiving the sensing notification request sent by the sensing server, the sensing client can send the sensing notification request to the operating system (OS) to request the OS to obtain and feedback the user's reply. The OS side can reply to the sensing notification request after obtaining the user's reply, such as replying to agree to be sensed or disagree to be sensed, or can also not reply when the user's reply is not obtained.

[0565] A possible situation is that the sensing client may receive a reply from the OS side or may not receive a reply from the OS side. The sensing client can indicate that the terminal replies to agree to be sensed, or indicates that the terminal replies to disagree to be sensed, or indicates that the terminal does not reply by sending a response message to the sensing server for the sensing notification request. The sensing server can obtain the sensing notification feedback according to the response message for the sensing notification request from the sensing client, and then determine whether the terminal is allowed to be sensed according to the sensing permission subscribed by the terminal and the sensing notification feedback.

[0566] Another possible situation is that the sensing client can indicate that the terminal replies to agree to be sensed, or indicates that the terminal replies to disagree to be sensed by sending a response message to the sensing server for the sensing notification request when receiving a reply from the OS side. The sensing client may also not obtain a reply from the OS side. At this time, the sensing client does not send a response message to the sensing server for the sensing notification request. And the sensing server can determine that the terminal does not reply according to the expiration of the local timer. In other words, step 7052 does not necessarily execute. The sensing server can obtain the sensing notification feedback according to the response message for the sensing notification request from the sensing client, which can specifically include: the sensing server can obtain the sensing notification feedback according to the information indicated by the response message for the sensing notification request from the sensing client, or according to whether it receives the response message for the sensing notification request from the sensing client.

[0567] For a more detailed description of step 705, refer to the relevant content in step 506 of method 500, which will not be elaborated here.

[0568] In step 706, the perception server obtains the target service requirement.

[0569] Optionally, step 706 includes: the perception server determines the target service requirement.

[0570] In a possible design, the service requirement can be pre-stored in the SF, and this service requirement can be called the default service requirement. The SF can directly determine the target service requirement when the terminal allows itself to be perceived.

[0571] In another possible design, the service requirement requested can be carried in the above perception request, and the SF can determine the service requirement of the request as the target service requirement when the terminal allows itself to be perceived. Or rather, the SF can also define the default service requirement as the service requirement of the request without pre-configuring the default service requirement.

[0572] In yet another possible design, the target service requirement can be determined according to the time information of the first perception request and / or the location of the terminal. That is to say, the perception server can determine the target service requirement according to the time information of the first perception request and / or the location of the terminal.

[0573] A possible implementation for the perception server to determine the target service requirement according to the time information of the first perception request and / or the location of the terminal is that the perception server determines the target service requirement according to the first mapping relationship and the time information of the first perception request, and this first mapping relationship can include the corresponding relationship between at least one service requirement and at least one time period.

[0574] Another possible implementation for the perception server to determine the target service requirement according to the time information of the first perception request and / or the location of the terminal is that the perception server determines the target service requirement according to the location of the terminal and the second mapping relationship, and this second mapping relationship includes the corresponding relationship between at least one service requirement and at least one area.

[0575] Another possible implementation for the perception server to determine the target service requirement according to the time information of the first perception request and / or the location of the terminal is that the perception server determines the target service requirement according to the time information of the first perception request, the location of the terminal, and the third mapping relationship, and this third mapping relationship includes the corresponding relationship between at least one service requirement and at least one combination of area and time period.

[0576] For a more detailed description of how the sensing server determines the target service requirements based on the time information of the first sensing request and / or the location of the terminal, refer to the relevant content in step 508a of method 500, which will not be elaborated here.

[0577] Optionally, step 706 includes: the sensing server obtains the target service requirements from the UDM.

[0578] The specific process by which the sensing server obtains the target service requirements from the UDM is similar to the specific process in step 508b of method 500 above, where the SF obtains the target service requirements from the UDM. Refer to the relevant description in step 805b, which will not be elaborated here.

[0579] For a more detailed description of step 706, refer to the relevant content in step 508 of method 500, which will not be elaborated here.

[0580] In step 707, the sensing server sends a service requirement confirmation request to the AS. This service requirement confirmation request is used to request the adoption of the target service requirements.

[0581] In step 708, the AS sends a service requirement confirmation reply to the sensing server. This service requirement confirmation reply indicates whether it agrees or disagrees to adopt the target service requirements.

[0582] The specific processes of steps 707 to 708 are similar to those of steps 509 to 510 of method 500. Refer to the relevant descriptions in steps 509 to 510 of method 500, which will not be elaborated here.

[0583] It can be understood that if the service requirement confirmation reply indicates agreement to adopt the target service requirements, steps 709 to 712 can be executed; if the service requirement confirmation reply indicates disagreement to adopt the target service requirements, step 713 can be executed.

[0584] In step 709, the sensing server sends a second sensing request to the SF. The second sensing request carries the target service requirements.

[0585] The sensing server can send a second sensing request to the SF when the AS agrees to adopt the target service requirements. The second sensing request carries the target service requirements.

[0586] The sensing server can process the first sensing request received in step 701 to obtain a second sensing requirement. For example, the sensing server can replace the external identifier of the terminal in the first sensing request with the SUPI of the terminal and can carry the target service requirements in the second sensing request. In other words, the second sensing request carries the SUPI of the terminal and the target service requirements, as well as one or more of the following: the identifier of the AS or the type of service requested.

[0587] In step 710, the SF initiates a sensing process for the terminal based on the target service requirement.

[0588] After receiving the second sensing request, the SF can initiate a sensing process for the terminal based on the target service requirement carried therein.

[0589] For the specific content of the SF initiating a sensing process for the terminal based on the target service requirement, reference can be made to the relevant description in step 511 of method 500, which will not be elaborated herein.

[0590] In step 711, the SF sends the sensing result to the sensing server.

[0591] After completing the sensing process for the terminal, the SF can send the sensing result to the sensing server.

[0592] In step 712, the sensing server sends the sensing result to the AS.

[0593] The sensing server can send the sensing result to the AS through the user plane.

[0594] In step 713, the sensing server sends a rejection message to the AS.

[0595] The sensing server can send the rejection message to the AS through the user plane.

[0596] The specific processes of steps 711 to 713 are similar to those of steps 512 to 513 of method 500. Reference can be made to the relevant description in steps 512 to 513 of method 500, which will not be elaborated herein.

[0597] As described above in conjunction with Figure 7 shows another possible process of the method provided in this application. Figure 7 The steps shown are only examples and do not mean that all steps must be executed. Figure 7 For example, step 703 and step 704 can be alternatively executed, step 709 to 712 and step 713 can be alternatively executed, and so on. The sequence numbers of the steps do not indicate the order of execution. The order of execution of each step should be determined by its function and internal logic.

[0598] It should be understood that method 700 has the same processing logic as method 500. Therefore, method 700 has similar technical effects to method 500, which will not be elaborated herein.

[0599] Figure 8 is another schematic flowchart of the sensing method provided in the embodiments of this application. Figure 8 The method 800 shown is similar to the processing flow of Figure 6 the method 600 shown, and is also similar to Figure 7The method 700 shown is applicable to the same network architecture. For the same or similar steps in method 600 or 700, and the descriptions of the same terms, reference can be made to the relevant descriptions in method 600 or 700 above; while method 700 is similar to Figure 5 the processing flow of the method 500 shown. For the same or similar steps in method 500, and the descriptions of the same terms, reference can also be made to the relevant descriptions in method 500 above, which will not be elaborated here.

[0600] As Figure 8 shown, the method 800 may include steps 801 to 813. Each step in method 800 will be described in detail below.

[0601] In step 801, the AS sends a first sensing request to the sensing server, and this first sensing request is used to request sensing of the terminal.

[0602] In step 802, the sensing server obtains authorization for the sensing request from the UDM.

[0603] The sensing server can obtain authorization from the UDM for this first sensing request by sending a sensing authorization request to the UDM. The UDM can indicate authorization or rejection of this first sensing request through a sensing authorization reply. In the case where the sensing authorization reply indicates rejection of authorization, step 803 can be executed. In the case where the sensing authorization reply indicates authorization, some steps from 804 to 813 can be executed.

[0604] In step 803, the sensing server sends a rejection message to the AS.

[0605] The specific processes of steps 801 to 803 are the same as those of steps 701 to 703 in method 700, and the specific processes of steps 701 to 703 in method 700 are similar to those of steps 501 to 503 in method 500. Therefore, reference can be made to steps 501 to 503 in method 500 and the relevant descriptions of 701 to 703 in method 700, which will not be elaborated here.

[0606] In step 804, the sensing server obtains the sensing notification feedback of the terminal.

[0607] The sensing server can obtain the sensing notification feedback of the terminal by sending a sensing notification request. Among them, this sensing notification request is used to request the terminal to reply whether it agrees to be sensed. Optionally, step 804 specifically includes: the sensing server sends a sensing notification request; the sensing server obtains the sensing notification feedback of the terminal according to the response message of the sensing notification request.

[0608] Different from methods 500 and 600, the sensing server can interact with the sensing client installed on the terminal at the user plane without having to go through the relay of the AMF and RAN nodes. Therefore, the sensing server can send the sensing notification request to the sensing client and receive the response message of the sensing notification request from the sensing client.

[0609] FIG. shows a possible implementation of step 804 from the perspective of device interaction. Exemplarily, step 804 includes the following steps 8041 to 8043:

[0610] Step 8041, the sensing server sends a sensing notification request to the sensing client.

[0611] Step 8042, the sensing client sends a response message of the sensing notification request to the sensing server, and the response message of the sensing notification request carries the sensing notification feedback.

[0612] Step 8043, the sensing server obtains the sensing notification feedback according to the response message of the sensing notification request.

[0613] For a more detailed description of step 804, reference can be made to the relevant content in step 704 of method 700, which will not be elaborated here.

[0614] Different from method 700, the sensing server can obtain the target service requirements without determining that the terminal allows to be sensed. Therefore, the sensing server does not need to first determine whether the terminal allows to be sensed, but directly executes step 805.

[0615] In step 805, the sensing server obtains the target service requirements.

[0616] In one implementation, the sensing server can determine the target service requirements according to the sensing permissions subscribed by the terminal and / or the sensing notification feedback of the terminal. In another implementation, the sensing server can send a service requirement request to the data management function network element, and the service requirement request carries the sensing notification feedback of the terminal. The data management function network element can determine the target service requirements according to the sensing permissions subscribed by the terminal and / or the sensing notification feedback of the terminal.

[0617] Furthermore, the target service requirements can also be determined in combination with the location and / or time information of the terminal. If the target service requirements are requested and obtained by the sensing server by sending a service requirement request to the data management function network element, correspondingly, the location information and / or time information is carried in the service requirement request.

[0618] In a specific implementation, the sensing server or the data management function network element can determine the target service requirements according to the mapping relationship and one or more of the following: the sensing permissions subscribed by the terminal, the sensing notification feedback, the time period or the area.

[0619] The specific process for the perception server to obtain the target service requirements is similar to the specific process of step 607 of method 600. For the relevant description, refer to step 607 of method 600 above and will not be elaborated here. In step 806, the perception server sends a service requirement confirmation request to the AS, and this service requirement confirmation request is used to request to adopt the target service requirements.

[0620] In step 807, the AS sends a service requirement confirmation reply to the perception server, and this service requirement confirmation reply indicates whether to agree or disagree to adopt the target service requirements.

[0621] In step 808, the perception server sends a second perception request to the SF, and the target service requirements are carried in this second perception request.

[0622] In step 809, the SF initiates a perception process for the terminal based on the target service requirements.

[0623] After receiving the second perception request, the SF can initiate a perception process for the terminal based on the target service requirements carried therein.

[0624] For the specific content of the SF initiating a perception process for the terminal based on the target service requirements, refer to the relevant description in step 511 of method 500 and will not be elaborated here.

[0625] In step 810, the SF sends a perception result to the perception server.

[0626] After completing the perception process for the terminal, the SF can send the perception result to the perception server.

[0627] In step 811, the perception server sends the perception result to the AS.

[0628] The perception server can send the perception result to the AS through the user plane.

[0629] In step 812, the perception server sends a rejection message to the AS.

[0630] The perception server can send the rejection message to the AS through the user plane.

[0631] The specific processes of steps 806 to 812 are the same as those of steps 707 to 713 of method 700. For the relevant description, refer to steps 707 to 713 of method 700 and will not be elaborated here.

[0632] As described above in combination with Figure 8 Another possible process of the method provided by the present application is shown. Figure 8 Each step shown is only an example and does not mean that it must be executed. Figure 8All steps in it, for example, step 803 and steps 804 to 812 can be alternatively executed, steps 808 to 811 and step 812 can be alternatively executed, and so on. The sequence numbers of the steps do not mean the order of execution, and the execution order of each step should be determined according to its function and internal logic.

[0633] It should be understood that method 800 has the same processing logic as method 600, so method 800 has similar technical effects to method 600, which will not be elaborated here.

[0634] As described above in conjunction with Figures 5 to 8 Exemplarily, several possible processes of the perception method provided by the present application are shown. It is not difficult to see that in Figures 5 to 8 the illustrated embodiment, the second communication device (such as Figure 5 and Figure 6 the SF in Figure 7 and Figure 8 or the perception server in Figure 9 ) can, after receiving the perception request, obtain the target service requirement, and the target service requirement is related to the perception permission of the terminal to which the perception request is sent. For ease of understanding, the following will be combined with Figure 9 to briefly describe the perception method provided by the present application.

[0635] Figure 9 FIG. is another schematic flowchart of the perception method provided by the embodiments of the present application. Figure 9 This method is shown from the perspective of device interaction. As Figure 9 shown, this method 900 includes steps 901 to 909.

[0636] The following details each step in method 900.

[0637] In step 901, the second communication device receives a perception request.

[0638] The perception request may be sent by the first communication device and forwarded to the second communication device via the third communication device. For example, it is sent from the AF to the NEF (i.e., an example of the third communication device), and then forwarded from the NEF to the SF. The third communication device may process the perception request before forwarding it, or directly forward it without processing. The present application does not limit this.

[0639] The perception request may also be directly sent by the first communication device to the second communication device. For example, it is sent from the AS to the perception server.

[0640] Exemplarily, the perception request may carry the external identifier of the terminal to be perceived and one or more of the following: the identifier of the AF, the type of the requested service, the requirements of the requested service, or the time information for requesting perception.

[0641] Step 901 may correspond to steps 501 to 503 in method 500 above, steps 601 to 603 in method 600, step 701 in method 700, or step 801 in method 800. Therefore, for the specific process of step 901, reference may be made to the relevant descriptions of the corresponding steps in method 500, method 600, method 700, or method 800 above, and no further elaboration will be provided.

[0642] In step 902, the second communication device obtains a target service requirement, and the target service requirement is related to the sensing permission of the terminal.

[0643] Among them, the target service requirement is related to the sensing permission of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be sensed, and / or the target service requirement is determined according to the sensing permission of the terminal.

[0644] Therefore, at least two processing logics are provided in this application to obtain the target service requirement.

[0645] One processing logic is to obtain the target service requirement when it is determined that the terminal is allowed to be sensed. Optionally, the method further includes step 903: the second communication device determines that the terminal is allowed to be sensed. The second communication device may determine that the terminal is allowed to be sensed according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal.

[0646] When it is determined that the terminal is allowed to be sensed, the second communication device may determine the target service requirement by itself, as shown in 902a in the figure, or may also request to obtain the target service requirement from the data management function network element, as shown in 902b in the figure. The target service requirement may be determined according to the location and / or time information of the terminal.

[0647] Step 903 may correspond to step 505 in method 500 above or step 704 in method 700. Therefore, for the specific process of step 903, reference may be made to the relevant descriptions of the corresponding steps in method 500 or 700 above, and no further elaboration will be provided.

[0648] In this processing logic, step 902 may correspond to step 508 in method 500 above or step 706 in method 700. Therefore, for the specific process of step 902, reference may be made to the relevant descriptions of the corresponding steps in method 500 or 700 above, and no further elaboration will be provided.

[0649] Another processing logic is to obtain the target service requirement without determining that the terminal is allowed to be sensed, and the target service requirement may be determined according to the sensing permission of the terminal, specifically according to the sensing permission subscribed by the terminal and the sensing notification feedback of the terminal.

[0650] After obtaining the perception notification feedback of the terminal, the second communication device can determine the target service requirements by itself, as shown in 902a in the figure, or it can also send a service requirement request to the data management function network element. The service requirement request carries the perception notification feedback and is used to request to obtain the target service requirements and send them to the data management function network element, as shown in 902b in the figure. The target service requirements can be determined according to the perception permissions subscribed by the terminal and / or the perception notification feedback. Further, the target service requirements can also be determined in combination with the location and / or time information of the terminal.

[0651] In this processing logic, step 902 can correspond to step 607 in method 600 or step 805 in method 800 above. Therefore, for the specific process of step 903, reference can be made to the relevant descriptions of the corresponding steps in method 600 or 800 above, and details will not be repeated.

[0652] It should be understood that the two processing logics exemplified above are only two possible implementation manners and should not constitute any limitation to this application. It is not difficult to see that both of these two processing logics are essentially related to the perception permissions of the terminal, and the perception permissions of the terminal can include the perception permissions subscribed by the terminal and / or the perception notification feedback of the terminal. Therefore, it can also be considered that the target service requirements are determined according to the perception permissions subscribed by the terminal and / or the perception notification feedback of the terminal. Therefore, in specific implementation, these two processing logics can be used alone or in combination. For example, after receiving a service requirement request carrying the perception notification feedback of the terminal, the data management function network element can first determine that the terminal is allowed to be perceived according to the perception permissions subscribed by the terminal and / or the perception notification feedback of the terminal, and then determine the target service requirements. This application does not make any limitation on this.

[0653] Further, in the two processing logics exemplified above, the second communication device can first obtain the perception notification feedback of the terminal, for example, before step 903 or before step 902, obtain the perception notification feedback of the terminal.

[0654] Optionally, the method further includes step 904 of obtaining the perception notification feedback of the terminal, where the perception notification feedback indicates that the terminal replies to agree to be perceived, the terminal replies to disagree to be perceived, or the terminal does not reply. Exemplarily, the second communication device can obtain the perception notification feedback of the terminal by sending a perception notification request.

[0655] Step 904 can correspond to step 506 in method 500, step 606 in method 600, step 705 in method 700, or step 804 in method 800. Therefore, for the specific process of step 904, reference can be made to the relevant descriptions of the corresponding steps in method 500, method 600, method 700, or method 800 above, and details will not be repeated.

[0656] Optionally, the method further includes step 905 where the second communication device sends a service requirement confirmation request to the first communication device, and the service requirement confirmation request is used to request to adopt the target service requirement. Correspondingly, the first communication device receives the service requirement confirmation request from the second communication device.

[0657] The second communication device may send a service requirement confirmation request to the first communication device when the target service requirement is different from the requested service requirement carried in the sensing request.

[0658] Optionally, the method further includes step 906 where the first communication device sends a service requirement confirmation reply to the second communication device, and the service requirement confirmation reply is used to indicate agreement or disagreement to adopt the target service requirement. Correspondingly, the second communication device receives the service requirement confirmation reply from the first communication device.

[0659] Optionally, the method further includes step 907 where the second communication device initiates a sensing process for the terminal based on the target service requirement.

[0660] If the service requirement confirmation reply indicates agreement to adopt the target service requirement, the second communication device may initiate a sensing process for the terminal based on the target service requirement.

[0661] Optionally, the method further includes step 908 where the second communication device sends a sensing result to the first communication device. Correspondingly, the first communication device receives the sensing result from the second communication device.

[0662] The second communication device may send the sensing result to the first communication device after obtaining the sensing result.

[0663] Optionally, the method further includes step 909 where the second communication device sends a rejection message to the first communication device, and the rejection message is used to reject the sensing request of the first communication device. Correspondingly, the first communication device receives the rejection message from the second communication device.

[0664] If the service requirement confirmation reply indicates disagreement to adopt the target service requirement, the second communication device may reject the sensing request.

[0665] Steps 905 to 909 may correspond to steps 509 to 513 in method 500, steps 608 to 612 in method 600, steps 707 to 713 in method 700, and steps 806 to 812 in method 800. Therefore, the specific processes of steps 905 to 909 can be referred to the relevant descriptions of the corresponding steps in method 500, method 600, method 700, or method 800 above, and will not be elaborated here.

[0666] Optionally, the method further includes: the second communication device obtains the sensing permission subscribed by the terminal and / or the mapping relationship for determining the target service requirement from the data management function network element. Correspondingly, the data management function network element sends the sensing permission subscribed by the terminal and / or the mapping relationship for determining the target service requirement to the second communication device.

[0667] In the solution provided in this application, the target service requirement for determining the KPI for sensing the terminal is related to the sensing permission of the terminal, so that the sensing process initiated for the terminal is adapted to the sensing permission of the terminal, rather than blindly and directly determining the KPI for sensing the terminal according to the service requirements requested by the AF network element or the AS, etc. Or rather, this application can obtain the target service requirement in terms of the terminal granularity. Specifically, the target service requirements of different terminals can be determined according to their respective corresponding sensing permissions. Therefore, considering the security requirements of different terminals, the target service requirements can be flexibly obtained according to the sensing permissions of different terminals, and then the sensing process is initiated for different terminals based on different KPIs, rather than blindly using the same KPI to sense all the terminals requested to be sensed according to the service requirements requested by the AF network element or the AS.

[0668] As described above, the sensing method provided in the embodiments of this application has been described in detail with reference to the accompanying drawings. Next, the devices provided in the embodiments of this application will be described in detail with reference to the accompanying drawings.

[0669] Figures 10 to 11 It is a schematic block diagram of a possible communication device provided in the embodiments of this application. These communication devices can be used to implement the functions of the second communication device, the data management function network element, or the first communication device in the above method embodiments, and thus can also achieve the beneficial effects possessed by the above method embodiments.

[0670] A communication device provided in this application is as Figure 10 shown. The communication device 1000 includes a communication unit 1010 and a processing unit 1020.

[0671] A possible design is that the communication device 1000 is used to implement the function of the second communication device in any one of the method embodiments shown in the above Figures 5 to 9 . For example, the notification device can be the second communication device in the method embodiment shown in Figure 9 , or the communication device can be the SF in the method embodiment shown in Figure 5 or Figure 6 , or it can also be the one shown in Figure 7 or Figure 8The perception server in the method embodiment shown may also be a component (such as a chip, a chip system, a processor, etc.) configured in the SF or the perception server, or may also be a logic module or software capable of implementing part or all of the functions of the SF or the perception server.

[0672] Exemplarily, the communication unit 1010 is used to receive a perception request, and the perception request is used to request to perceive the terminal; the processing unit 1020 is used to obtain a target service requirement, and the target service requirement is used to determine the KPI for perceiving the terminal. The target service requirement is related to the perception permission of the terminal, and the perception permission is used to determine whether the terminal is allowed or not allowed to be perceived.

[0673] Optionally, the processing unit 1020 is specifically used to obtain the target service requirement when it is determined that the terminal is allowed to be perceived.

[0674] Optionally, the processing unit 1020 is specifically used to determine that the terminal is allowed to be perceived according to the perception permission subscribed by the terminal and / or the perception notification feedback, and the perception notification feedback indicates that the terminal replies to agree to be perceived or the terminal does not reply.

[0675] Optionally, the communication unit 1010 is further used to obtain the perception permission subscribed by the terminal from the data management function network element.

[0676] Optionally, the communication unit 1010 is further used to send a service requirement request to the data management function network element, and the service requirement request indicates that the terminal is allowed to be perceived; and is used to receive the target service requirement from the data management function network element, and the target service requirement is determined based on the service requirement request.

[0677] Optionally, the communication unit 1010 is further used to send a service requirement request to the data management function network element; and is used to receive the target service requirement from the data management function network element, and the target service requirement is determined based on the service requirement request.

[0678] Optionally, the service requirement request carries the perception notification feedback, and the perception notification feedback indicates that the terminal replies to agree to be perceived or the terminal does not reply to the perception notification request, and the perception notification request is used to request the terminal to reply to agree or disagree to be perceived.

[0679] Optionally, the communication unit 1010 is further used to send a perception notification request, and the perception notification request is used to request the terminal to reply to agree or disagree to be perceived; the processing unit 1020 is further used to obtain the perception notification feedback according to the response message of the perception notification request.

[0680] Optionally, the service requirement request message further includes the location information of the terminal and / or the time information of the sensing request.

[0681] Optionally, the sensing request indicates the service type of the request, and the service requirement request message also indicates the service type.

[0682] Optionally, the processing unit 1020 is specifically configured to determine the target service requirement according to the location of the terminal and / or the time information of the sensing request.

[0683] Optionally, the processing unit 1020 is specifically configured to determine the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and the mapping relationship. The sensing notification feedback indicates that the terminal agrees to be sensed in response to the sensing notification request or the terminal does not respond to the sensing notification request. The sensing notification request is used to request the terminal to reply whether it agrees to be sensed. The mapping relationship includes the corresponding relationship between at least one combination of the sensing permission and the sensing notification feedback and at least one service requirement.

[0684] Optionally, the communication unit 1020 is further configured to receive the mapping relationship from the data management function network element.

[0685] Optionally, the sensing request comes from a first communication device, and the requested service requirement is also carried in the sensing request. The communication unit 1010 is further configured to: send a service requirement confirmation request to the first communication device, where the service requirement confirmation request is used to request to adopt the target service requirement, and the target service requirement is different from the requested service requirement; receive a service requirement confirmation reply from the first communication device, where the service requirement confirmation reply indicates whether to agree to adopt the target service requirement; the processing unit 1020 is further configured to, when the service requirement confirmation reply indicates agreeing to adopt the target service requirement, initiate a sensing process for the terminal based on the target service requirement; the communication unit 1010 is further configured to, when the service requirement confirmation reply indicates disagreeing to adopt the target service requirement, send a rejection message to the first communication device, where the rejection message is used to reject the sensing request.

[0686] Optionally, the communication unit 1010 is further configured to send a rejection message to the first communication device when it is determined that the terminal is not allowed to be sensed, where the rejection message is used to reject the sensing request.

[0687] Optionally, the rejection message also indicates the reason for rejecting the sensing request.

[0688] For a more detailed description of the above communication unit 1010 and processing unit 1020, reference can be directly made to Figures 5 to 9The relevant descriptions in the method embodiments shown can be directly obtained and will not be elaborated here.

[0689] A possible design is that the communication device 1000 is used to implement the function of the data management function module (such as UDM) in any one of the method embodiments shown above. For example, the communication device can be the UDM in any one of the method embodiments shown, or the data management function network element in the method embodiment shown, or can also be a component (such as a chip, a chip system, a processor, etc.) configured in the UDM or other data management function network elements, or can also be a logical module or software capable of implementing part or all of the functions of the UDM or other data management function network elements. Figures 5 to 9 For example, the communication device can be the UDM in any one of the method embodiments shown, or the data management function network element in the method embodiment shown, or can also be a component (such as a chip, a chip system, a processor, etc.) configured in the UDM or other data management function network elements, or can also be a logical module or software capable of implementing part or all of the functions of the UDM or other data management function network elements. Figures 5 to 8 For example, the communication device can be the UDM in any one of the method embodiments shown, or the data management function network element in the method embodiment shown, or can also be a component (such as a chip, a chip system, a processor, etc.) configured in the UDM or other data management function network elements, or can also be a logical module or software capable of implementing part or all of the functions of the UDM or other data management function network elements. Figure 9 For example, the communication device can be the UDM in any one of the method embodiments shown, or the data management function network element in the method embodiment shown, or can also be a component (such as a chip, a chip system, a processor, etc.) configured in the UDM or other data management function network elements, or can also be a logical module or software capable of implementing part or all of the functions of the UDM or other data management function network elements.

[0690] Exemplarily, the communication unit 1010 is used to receive a service requirement request from a second communication device, the service requirement request is used to request to obtain a target service requirement, and the target service requirement is used to determine the KPIs for sensing the terminal; the processing unit 1020 is used to determine the target service requirement, and the target service requirement is related to the sensing permission of the terminal; the communication unit 1010 is further used to send the target service requirement to the second communication device.

[0691] Optionally, the service requirement request carries a sensing notification feedback, the sensing notification feedback indicates that the terminal agrees to be sensed in response to a sensing notification request or the terminal does not respond to the sensing notification request, and the sensing notification request is used to request whether the terminal agrees to be sensed. The processing unit 1020 is specifically used to determine the target service requirement according to the sensing permission of the terminal, the sensing notification feedback and the mapping relationship, and the mapping relationship includes the corresponding relationship between at least one combination of the sensing permission and the sensing notification feedback and at least one service requirement.

[0692] Optionally, the service requirement request indicates that the terminal allows to be sensed and one or more of the following: the location of the terminal, the time information of the sensing request or the time information of the service requirement request, and the sensing request is used to request to sense the terminal. The processing unit 1020 is specifically used to determine the target service requirement according to one or more of the following: the location of the terminal, the time information of the sensing request or the time information of the service requirement request.

[0693] Optionally, the communication unit 1020 is further used to receive the sensing permission of the terminal signed by the second communication device.

[0694] Exemplarily, the communication unit 1020 is configured to: receive a sensing authorization request from a third communication device, where the sensing authorization request is used to request authorization for a sensing request, and the sensing request is used to request to sense a terminal; and send a sensing authorization reply to the third communication device according to the sensing permission of the terminal, where the sensing authorization reply indicates authorization for the sensing request or refusal of authorization for the sensing request.

[0695] Optionally, the sensing authorization reply indicates authorization for the sensing request, and the sensing authorization reply carries the sensing permission subscribed by the terminal and / or a mapping relationship for determining target service requirements, where the target service requirements are used to determine the KPIs for sensing the terminal.

[0696] For a more detailed description of the foregoing communication unit 1010 and processing unit 1020, reference can be directly made to Figures 5 to 9 the relevant descriptions in the method embodiments shown, which will not be elaborated here.

[0697] It should be noted that the communication unit may also be referred to as a transceiver unit, a transceiver module, a transceiver, a transceiver machine, or a transceiver device, etc. The processing unit may also be referred to as a processor, a processing board, a processing module, or a processing device, etc. Optionally, the communication unit is configured to perform the sending operation and the receiving operation of the second communication device or the data management function module in the foregoing method. The device in the communication unit for implementing the receiving function may be regarded as a receiving unit, and the device in the communication unit for implementing the sending function may be regarded as a sending unit. That is, the communication unit includes a receiving unit and a sending unit.

[0698] It should also be noted that in a possible design, the foregoing communication unit and / or processing unit may be implemented by a virtual module. For example, the processing unit may be implemented by a software functional unit or a virtual device, and the communication unit may be implemented by a software function or a virtual device. In another possible design, the processing unit or the communication unit may also be implemented by a physical device. For example, if the device is implemented by a chip / chip circuit, the communication unit may be an input / output circuit and / or a communication interface, performing an input operation (corresponding to the foregoing receiving operation) and an output operation (corresponding to the foregoing sending operation); the processing unit is an integrated processor or a microprocessor or an integrated circuit.

[0699] The division of units in the embodiments of the present application is illustrative, merely a logical function division, and there may be other division methods in actual implementation. In addition, in each example of the embodiments of the present application, each functional module may be integrated in a processor, may exist separately physically, or two or more modules may be integrated in one module. The foregoing integrated module may be implemented in the form of hardware or in the form of a software functional module.

[0700] Another communication device provided by this application is as follows Figure 11 As shown, the communication device 1100 includes at least one processor 1110. The at least one processor 1110 can be used to execute computer programs or instructions in the memory to implement Figures 5 to 9 The steps executed by the second communication device (such as SF or the sensing server), the steps executed by the data management function network element (such as UDM), or the steps executed by the first communication device (such as AS or AF) in any of the method embodiments shown.

[0701] Optionally, the communication device 1100 may further include at least one memory 1120, which is used to store the instructions executed by the processor 1110, or store the input data required for the processor 1110 to run the instructions, or store the data generated after the processor 1110 runs the instructions. The at least one processor 1110 and the at least one memory 1120 can be separately provided. For example, each memory can be connected to one or more processors, so that the connected processors can read information from the memory, store and / or write information in the memory. Or, the at least one processor 1110 and the at least one memory 1120 can be integrated together. For example, one or more memories can be integrated in one processor.

[0702] Optionally, the communication device 1100 further includes an interface circuit 1130, which can be used to transmit data and / or signaling. The at least one processor 1110 and the interface circuit 1130 are coupled to each other. It can be understood that the interface circuit 1130 can be a transceiver, an input / output circuit, a bus, a module, a pin, or other types of communication interfaces. Among them, the input circuit in the input / output circuit can be used for receiving, and the output interface can be used for sending.

[0703] Optionally, the communication device 1100 further includes a power supply circuit 1140, which can be used to supply power to the communication device 1100.

[0704] When the communication device 1100 is used to implement Figures 5 to 9 the method shown, the processor 1111 is used to execute the functions of the above-mentioned processing unit, and the interface circuit 1120 is used to execute the functions of the above-mentioned receiving unit and / or sending unit. Whether the interface circuit 1120 is used for sending or receiving specifically depends on whether the communication device 1100 executes a sending action or a receiving action in the implemented solution.

[0705] It can be understood that when the communication device 1100 is a communication equipment (such as an SF, a perception server, a data management function network element, an AF, or an AS), the interface circuit 1120 can be a transceiver, specifically including a transmitter and a receiver. The transmitter is used to send signals, and the receiver is used to receive signals. When the communication device 1100 is a chip applied to a communication equipment, the interface circuit 1120 can be an input / output circuit, a bus, a module, a pin, or other types of communication interfaces. Among them, the input circuit in the input / output circuit can be used for receiving, and the output interface can be used for sending.

[0706] It should be understood that Figure 11 In the communication device 1100 shown, the processor 1110 can correspond to the processing unit 1020 in the communication device 1000 above, and the interface circuit 1120 can correspond to the communication unit 1010 in the communication device 1000 above.

[0707] It should also be understood that the coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, and is used for information interaction between devices, units, or modules. In the embodiments of the present application, the specific connection medium between at least one of the above-mentioned processor 1110, at least one memory 1120, interface circuit 1130, and power supply circuit 1140 is not limited. In the embodiments of the present application Figure 11 it is connected by a bus 1150 between the processor 1110, the memory 1120, the interface circuit 1130, and the power supply circuit 1140. The bus 1150 is Figure 11 shown by a thick line. The connection manners between other components are only for illustrative purposes and are not limited thereto. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 11 only one thick line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0708] It can be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0709] The memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include but not be limited to these and any other suitable types of memory.

[0710] The present application also provides a communication system, which includes one or more of the foregoing first communication device, second communication device, or data management function network element.

[0711] Exemplarily, the communication system includes an SF and a UDM. Optionally, the communication system further includes a sensing server. Optionally, the communication system further includes a NEF.

[0712] The present application also provides a computer program product, which includes: a computer program (which can also be referred to as code, or instructions). When the computer program is run, it causes the computer to execute the methods performed by the second communication device, the data management function network element, or the first communication device in the embodiment shown in FIG. 9, or causes the computer to execute the method performed by the data management function network element in any one of the embodiments shown in Figures 5 to 8 the embodiments shown, or causes the computer to execute the method performed by the SF in the embodiment shown in Figure 5 or Figure 6 the embodiments shown, or causes the computer to execute the method performed by the sensing server in Figure 7 or Figure 8 .

[0713] The present application also provides a computer-readable storage medium, which stores a computer program (which can also be referred to as code, or instructions). When the computer program is run, it causes the computer to execute the methods performed by the second communication device, the data management function network element, or the first communication device in the embodiment shown in FIG. 9, or causes the computer to execute the method performed by the data management function network element in any one of the embodiments shown in Figures 5 to 8 the embodiments shown, or causes the computer to execute the method performed by the SF in the embodiment shown in Figure 5 or Figure 6 the embodiments shown, or causes the computer to execute the method performed by the sensing server in Figure 7 or Figure 8 .

[0714] The terms "unit", "module", etc. used in this specification can be used to represent computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution.

[0715] Those of ordinary skill in the art can realize that the various illustrative logical blocks and steps described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application. In several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling, direct coupling, or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical, or other form.

[0716] The unit described as a separate component may or may not be physically separated. The component displayed as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0717] In addition, each functional unit in the various embodiments of this application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0718] In the above embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a digital video disc (DVD)), or a semiconductor medium (such as a solid-state disk (SSD)), etc.

[0719] If this function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks, or optical discs that can store program codes.

[0720] As described above, the above are only the specific implementation manners of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present application can easily think of changes or substitutions, which should all be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A perception method, characterized in that, Including: Receiving a sensing request for requesting to sense a terminal; Obtaining a target service requirement for determining key performance indicators (KPIs) for sensing the terminal, where the target service requirement is related to the sensing permission of the terminal, and the sensing permission is used to determine whether the terminal is allowed or not allowed to be sensed.

2. The method according to claim 1, characterized in that, The obtaining of the target service requirement includes: When it is determined that the terminal is allowed to be sensed, obtaining the target service requirement.

3. The method according to claim 2, characterized in that, The determining that the terminal is allowed to be sensed includes: Determining that the terminal is allowed to be sensed according to the sensing permission subscribed by the terminal and / or the sensing notification feedback of the terminal, where the sensing notification feedback indicates that the terminal replies to agree to be sensed or the terminal does not reply.

4. The method according to claim 3, characterized in that The method further includes: Sending a sensing notification request for requesting the terminal to reply whether it agrees or disagrees to be sensed; Obtaining the sensing notification feedback according to the response message of the sensing notification request.

5. The method according to claim 3 or 4, characterized in that, The method further includes: Obtaining the sensing permission subscribed by the terminal from a data management function network element.

6. The method according to any one of claims 1 to 5, characterized in that The obtaining of the target service requirement includes: Sending a service requirement request to a data management function network element; Receiving the target service requirement from the data management function network element, where the target service requirement is determined based on the service requirement request.

7. The method according to claim 6, wherein The service requirement request carries the sensing notification feedback, where the sensing notification feedback indicates that the terminal replies to agree to be sensed for the sensing notification request or the terminal does not reply, and the sensing notification request is for requesting the terminal to reply whether it agrees or disagrees to be sensed.

8. The method according to claim 6 or 7, characterized in that, The service requirement request message further includes the location information of the terminal and / or the time information of the sensing request.

9. The method according to any one of claims 6 to 8, characterized in that The sensing request indicates the requested service type, and the service requirement request message also indicates the service type.

10. The method according to any one of claims 2 to 5, characterized in that, The obtaining of the target service requirement includes: Determining the target service requirement according to the location of the terminal and / or the time information of the sensing request.

11. The method according to any one of claims 1 to 5, characterized in that, The obtaining of the target service requirement includes: Determining the target service requirement according to the sensing permission subscribed by the terminal, the sensing notification feedback, and a mapping relationship, where the sensing notification feedback indicates that the terminal replies to agree to be sensed for the sensing notification request or the terminal does not reply to the sensing notification request, the sensing notification request is for requesting the terminal to reply whether it agrees to be sensed, and the mapping relationship includes the corresponding relationship between at least one combination of the sensing permission and the sensing notification feedback and at least one service requirement.

12. The method according to claim 11, wherein The method further includes: Receiving the mapping relationship from a data management function network element.

13. The method according to any one of claims 1 to 12, characterized in that, The sensing request comes from a first communication device, and the sensing request also carries the requested service requirement. The method further includes: Sending a service requirement confirmation request to the first communication device, where the service requirement confirmation request is for requesting to adopt the target service requirement, and the target service requirement is different from the requested service requirement; Receiving a service requirement confirmation reply from the first communication device, where the service requirement confirmation reply indicates whether it agrees or disagrees to adopt the target service requirement; and In the case that the business requirement confirmation reply indicates consent to adopt the target business requirement, initiate a sensing process for the terminal based on the target business requirement; or In the case that the business requirement confirmation reply indicates disagreement to adopt the target business requirement, send a rejection message to the first communication device, where the rejection message is used to reject the sensing request.

14. The method according to claim 1, characterized in that, The sensing request comes from a first communication device, and the method further includes: In the case of determining that the terminal is not allowed to be sensed, send a rejection message to the first communication device, where the rejection message is used to reject the sensing request.

15. The method according to claim 13 or 14, characterized in that, The rejection message also indicates the reason for rejecting the sensing request.

16. A perception method, characterized in that, Includes: Receive a business requirement request from a second communication device, where the business requirement request is used to request to obtain a target business requirement, and the target business requirement is used to determine the key performance indicator (KPI) for sensing the terminal; Determine the target business requirement, where the target business requirement is related to the sensing permission of the terminal; Send the target business requirement to the second communication device.

17. The method according to claim 16, wherein The business requirement request carries a sensing notification feedback, where the sensing notification feedback indicates that the terminal agrees to be sensed in response to the sensing notification request or the terminal does not respond to the sensing notification request, and the sensing notification request is used to request the terminal to reply whether it agrees to be sensed; And The determining the target business requirement includes: Determine the target business requirement according to the sensing permission of the terminal, the sensing notification feedback, and a mapping relationship, where the mapping relationship includes the corresponding relationship between at least one combination of sensing permission and sensing notification feedback and at least one business requirement.

18. The method according to claim 16, wherein The business requirement request indicates that the terminal is allowed to be sensed and one or more of the following: the location of the terminal, the time information of the sensing request, or the time information of the business requirement request, where the sensing request is used to request to sense the terminal; And The determining the target business requirement includes: Determine the target business requirement according to one or more of the following: the location of the terminal, the time information of the sensing request, or the time information of the business requirement request.

19. The method according to any one of claims 16 to 18, characterized in that, The method further includes: Send the sensing permission subscribed by the terminal to the second communication device.

20. The method according to any one of claims 16 to 19, characterized in that The method further includes: Receive a sensing authorization request from a third communication device, where the sensing authorization request is used to request authorization for a sensing request, and the sensing request is used to request to sense a terminal; According to the sensing permission of the terminal, send a sensing authorization reply to the third communication device, where the sensing authorization reply indicates authorization for the sensing request or refusal to authorize the sensing request.

21. The method according to claim 20, wherein The sensing authorization reply indicates authorization for the sensing request, and the sensing authorization reply carries the sensing permission subscribed by the terminal and / or the mapping relationship used to determine the target business requirement.

22. A perception method, characterized in that, Includes: Receive a sensing authorization request, where the sensing authorization request is used to request authorization for a sensing request, and the sensing request is used to request to sense a terminal; Send a sensing authorization reply according to the sensing permissions subscribed by the terminal, where the sensing authorization reply indicates authorization for the sensing request or rejection of the sensing request.

23. The method according to claim 22, characterized in that, The sensing authorization reply indicates authorization for the sensing request, and the sensing permissions subscribed by the terminal and / or the mapping relationship used to determine the target service requirements are carried in the sensing authorization reply. The target service requirements are used to determine the key performance indicator (KPI) for sensing the terminal.

24. The method according to any one of claims 1 to 23, characterized in that, The sensing permissions subscribed by the terminal are: not allowed to be sensed, allowed to be sensed, allowed to be sensed and the terminal needs to be notified but no feedback from the terminal is required, needs to notify the terminal and is allowed to be sensed when the terminal replies consent or does not reply, or needs to notify the terminal and is allowed to be sensed only when the terminal replies consent.

25. A communication device, characterized in that, Comprising one or more functional units for implementing the method according to any one of claims 1 to 24.

26. A communication device, characterized in that, Comprising a processor, the processor is configured to execute program code to enable the communication device to implement the method according to any one of claims 1 to 24.

27. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the method according to any one of claims 1 to 24 is executed.

28. A computer program product, characterized in that, Comprising a computer program, when the computer program is run, the method according to any one of claims 1 to 24 is executed.

Images