Sensing method, communication apparatus, and system

Abstract

Provided are a sensing method, a communication apparatus, and a system. In the method, a network element responsible for a sensing management function, such as an SF or sensing server, receives a sensing request, and then acquires a target service requirement on the basis of the sensing request, wherein the target service requirement is used for determining a KPI for sensing a terminal, and the determination of the target service requirement is related to the sensing permission of the terminal. When the target service requirement is different from a service requirement carried in the sensing request, the SF or sensing server can also confirm with an external server (such as an AS or AF) whether the target service requirement is approved for use; and then, when the target service requirement is approved for use, the SF or sensing server initiates a sensing process for the terminal on the basis of the target service requirement. In the method, a target service requirement is acquired on the basis of the sensing permission of a terminal, such that a response can be flexibly made to a sensing request message according to a security requirement of a terminal device, thereby meeting the security requirements of different terminal devices.

Description

Perception method, communication device and system

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on January 12, 2024, with application number 202410053504.3 and application name “Perception Method, Communication Device and System”, the entire contents of which are incorporated by reference into this application. Technical Field

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

[0003] In mobile communication networks, some base stations or terminals in the radio access network (RAN) can function as sensing nodes due to their electromagnetic wave sensing capabilities. This sensing process is similar to the principles of radar. Specifically, a transmitter transmits electromagnetic waves, which are reflected by the object to be sensed and then captured by a receiver. The receiver then processes the reflected signals (referred to as raw sensing data) to generate sensing data, which can then be used to generate sensing results. Both these transmitters and receivers are referred to as sensing nodes.

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

[0005] Currently, there is no relevant secure process for the perception process of specific terminals. Summary of the Invention

[0006] The present application provides a perception method, a communication device and a system, in order to flexibly respond to perception request messages according to the security requirements of the terminal device, thereby meeting the security requirements of different terminal devices.

[0007] In a first aspect, a sensing method is provided. The method can be applied to a second communication device. The second communication device can be, for example, a sensing function (SF) network element or a sensing server, or a component configured in the SF network element or sensing server, such as a processor, chip, or chip system, or a logic module or software capable of implementing all or part of the functions of the second communication device. This application is not limited to this.

[0008] The method includes: receiving a perception request, which is used to request perception of a terminal; obtaining a target business requirement, which is used to determine a key performance indicator (KPI) for perceiving the terminal, and the target business requirement is related to the perception authority of the terminal, and the perception authority is used to determine whether the terminal is allowed or not to be perceived.

[0009] The perception request may be, for example, a perception request from a first communication device (such as an AF network element or an AS), which may be used to request perception of one or more terminals. For ease of understanding and explanation, the method provided herein is described using a request for perception of a terminal as an example. The terminal may be any terminal for which perception is requested.

[0010] In the solution provided by the present application, the target business requirements for determining the KPI for perceiving the terminal are related to the perception authority of the terminal, so that the perception process initiated for the terminal is adapted to the perception authority of the terminal, rather than blindly determining the KPI for perceiving the terminal directly based on the business requirements requested by the AF network element or AS. In other words, the present application can obtain target business requirements based on the terminal granularity. Specifically, the target business requirements of different terminals can be determined according to their corresponding perception authority. Therefore, taking into account the security needs of different terminals, different target business requirements are flexibly obtained according to the perception authority of different terminals, and then the perception process is initiated for different terminals based on different KPIs, rather than blindly using the same KPI to perceive all terminals requested for perception based on the business requirements requested by the AF network element or AS.

[0011] Optionally, the perception authority of the terminal includes: the perception authority subscribed by the terminal, the perception notification feedback of the terminal, or a result of whether the terminal is allowed to be perceived determined by the perception authority subscribed by the terminal and the perception notification feedback of the terminal.

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

[0013] The terminal's contracted sensing rights are the sensing rights that the terminal has signed with the network operator. They can also be called configured sensing rights, default sensing rights, or network-stored sensing rights. For example, a terminal can specify whether it allows sensing by signing a contract with the operator.

[0014] Exemplarily, the sensing authority contracted 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 requiring notification to the terminal (but requiring no terminal reply), etc.

[0015] It is not difficult to see that the perception authority signed by the terminal can indicate whether the terminal is allowed or not to be perceived.

[0016] The terminal's perception notification feedback indicates the terminal's response to a received perception notification request. This can be used to indicate whether the terminal agrees or disagrees to be perceived, and can be used to determine whether the terminal allows or disallows perception. Therefore, it can also be referred to as the perception permission of the terminal feedback. For example, a second communication device that receives a perception request can send a perception notification request to the terminal, which can be used to request the terminal to respond whether it agrees to be perceived.

[0017] In some cases, it may not be possible to determine whether the terminal allows perception simply based on the perception authority signed by the terminal or the perception notification feedback of the terminal, and a combination of the two is required to determine.

[0018] Exemplarily, the perception rights contracted by the terminal are: the terminal needs to be notified, and perception is allowed when the terminal replies with consent or does not reply, or the terminal needs to be notified, and perception is allowed only when the terminal replies with consent.

[0019] Among them, "need to notify the terminal, and allow to be perceived when the terminal replies with consent or does not reply" specifically means: need to notify the terminal, and allow to be perceived when the terminal replies with consent or does not reply, and do not allow to be perceived when the terminal replies with disagreement; "need to notify the terminal, and allow to be perceived only when the terminal replies with consent" specifically means: need to notify the terminal, and allow to be perceived when the terminal replies with consent, and do not allow to be perceived when the terminal replies with disagreement or does not reply.

[0020] Whether a terminal allows perception can be determined based on whether the terminal responds to a received perception notification request or the content of the response. For example, a second communication device that receives a perception request can send a perception notification request to the terminal based on the perception permissions subscribed to the terminal. The perception notification request can be used to request the terminal to respond whether it agrees to be perceived. The terminal can respond with either yes or no to the perception notification request. That is, if the perception notification feedback from the terminal indicates that the terminal responds with yes, then the perception permissions of the terminal indicate that perception is permitted. Alternatively, if the perception notification feedback from the terminal indicates that the terminal responds with no consent, then the perception permissions of the terminal indicate that perception is not permitted. The terminal can also not respond to the perception notification request. That is, if the perception notification feedback from the terminal indicates that the terminal has not responded, then the terminal's perception permissions can be combined with the perception permissions subscribed to the terminal to determine: if the perception permissions subscribed to the terminal require notification of the terminal and allow perception if the terminal responds with yes or no response, then the perception permissions of the terminal indicate that the terminal allows perception; if the perception permissions subscribed to the terminal require notification of the terminal and allow perception only if the terminal responds with yes, then the perception permissions of the terminal indicate that perception is not permitted.

[0021] In summary, whether the terminal allows or does not allow perception is determined according to the perception authority subscribed by the terminal and / or the perception notification feedback of the terminal.

[0022] In combination with the first aspect, in some possible implementations of the first aspect, the perception authority of the terminal contract includes one or more of the following: allowing perception, not allowing perception, allowing perception and requiring notification of the terminal but without the terminal replying, requiring notification of the terminal and allowing perception if the terminal replies in agreement or does not reply, or requiring notification of the terminal and allowing perception only if the terminal replies in agreement.

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

[0024] Of course, these enumerations are only examples, and the perception authority of the terminal contract can be any one of the items listed above, or can also be other authorities, and this application includes but is not limited to this.

[0025] Furthermore, the perception authority of the terminal contract may correspond to at least one area, and / or the perception authority of the terminal contract may correspond to at least one time period.

[0026] The sensing rights of the terminal contract may vary depending on the location and / or time. For example, the sensing rights of the terminal contract may be different in area 1 and area 2, or in time period 1 and time period 2, etc.

[0027] By monitoring the perception rights of the same terminal at different locations and / or at different time periods, the security requirements of the terminal can be further met, so that the second communication device can respond to the perception request more flexibly according to the perception rights of the terminal.

[0028] In combination with the first aspect, in some possible implementations, the target service requirement is related to the perception authority of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be perceived, and / or the target service requirement is determined based on the perception authority of the terminal.

[0029] The target service requirement is obtained when it is determined that the terminal allows perception. That is, if it is determined that the terminal allows perception, the target service requirement is obtained; if it is determined that the terminal does not allow perception, the target service requirement is not obtained. Whether the terminal allows or does not allow perception is determined by the terminal's perception authority, or in other words, the terminal's perception authority. Therefore, the target service requirement is related to the terminal's perception authority.

[0030] Correspondingly, the acquiring the target service requirement includes: acquiring the target service requirement when it is determined that the terminal is allowed to be perceived.

[0031] The determination that the terminal is allowed to be sensed is, that is, the determination that the terminal is allowed to be sensed is made based on the sensing authority of the terminal, or in other words, the sensing authority of the terminal indicates that the terminal is allowed to be sensed.

[0032] Optionally, determining whether the terminal is allowed to be perceived includes: determining whether the terminal is allowed to be perceived according to the perception authority subscribed by the terminal and / or perception notification feedback, where the perception notification feedback indicates that the terminal replies that it agrees to be perceived or that the terminal has not replied.

[0033] In other words, whether the terminal allows or does not allow being sensed can be determined based on the sensed authority subscribed to and / or the sensed notification feedback of the terminal.

[0034] It should be understood that the above has detailed several possible implementation methods for determining whether the terminal is allowed to be perceived with respect to the perception authority of the terminal. The specific implementation method for determining whether the terminal is allowed to be perceived can be found above and will not be repeated here.

[0035] Furthermore, the method further includes: sending a perception notification request, the perception notification request being used to request the terminal to reply to agree or disagree to be perceived; and obtaining the perception notification feedback according to a response message to the perception notification request.

[0036] That is, the terminal's perception notification feedback is obtained by sending a perception notification request to the terminal. The response message to the perception notification request may be a response message to the perception notification request, and may be used to indicate the perception notification feedback. One possible design is that the response message to the perception notification request carries the perception notification feedback.

[0037] The perception authority of the terminal contract can be obtained from the data management function network element or pre-configured in the second communication device, which is not limited in this application. If the perception authority of the terminal contract is obtained from the data management function network element, optionally, the method further includes: obtaining the perception authority of the terminal contract from the data management function network element.

[0038] The target service requirement is determined based on the perception rights of the terminal, which may include: the target service requirement is determined based on the perception rights subscribed by the terminal and / or the perception notification feedback of the terminal, or the target service requirement is determined based on the result of the terminal allowing perception, and the result of the terminal allowing perception is determined based on the perception rights subscribed by the terminal and / or the perception notification feedback of the terminal. Therefore, alternatively, the target service requirement is determined based on the perception rights subscribed by the terminal and / or the perception notification feedback.

[0039] The target service requirement may 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 may be determined by the second communication device.

[0040] The target service requirement may be obtained when it is determined that the terminal is allowed to be sensed, or may be obtained when it is not determined that the terminal is allowed to be sensed. Various possible implementations are provided below.

[0041] In a possible implementation manner, the target service requirement is acquired from a data management function network element.

[0042] Optionally, obtaining the target service requirement when it is determined that the terminal is allowed to be perceived includes: sending a service requirement request to the data management function network element when it is determined that the terminal is allowed to be perceived; receiving the target service requirement from the data management function network element, the target service requirement being determined based on the service requirement request.

[0043] One possible scenario is that the service requirement request may be sent to the data management function network element when the second communication device determines that the terminal allows perception. In other words, the sending of the service requirement request may be triggered by the condition that the terminal allows perception. After receiving the service requirement request, the data management function network element may determine the target service requirement and send it to the second communication device. In other words, sending the service requirement request can be used to implicitly indicate that the terminal allows perception. Upon receiving the service requirement request, the data management function network element may assume that the terminal allows perception.

[0044] Alternatively, the service requirement request may be sent as a result of the second communication device determining whether the terminal is permitted to be perceived, and the service requirement request may indicate whether the terminal permits or disallows perception through the second communication device. In other words, regardless of whether the terminal permits perception, the second communication device may send the service requirement request to the data management function network element. The data management function network element may first determine whether the terminal is permitted to be perceived based on the received service requirement request. If the terminal permits perception, the data management function network element may determine and send the target service requirement to the second communication device. However, if the terminal does not permit perception, the target service requirement need not be determined. In other words, the data management function network element does not necessarily have to determine and send the target service requirement.

[0045] Optionally, the service requirement request carries perception notification feedback, which indicates that the terminal responds to the perception notification request to agree to be perceived or the terminal does not respond. The perception notification request is used to request the terminal to respond to agree or disagree to be perceived.

[0046] That is, if it is not determined that the terminal allows perception, the target service requirement is obtained from the data management function network element through a service requirement request. This service requirement request carries the perception notification feedback. That is, the second communication device directly notifies the data management function network element of the perception notification feedback, and the data management function network element determines the target service requirement based on the perception notification feedback and the perception rights subscribed by the terminal. The data management function network element can further determine the target service requirement if it is determined that the terminal allows perception, or it can directly determine the target service requirement based on the perception rights subscribed by the terminal and the perception notification feedback.

[0047] Furthermore, the method further includes: sending a perception notification request, the perception notification request being used to request the terminal to reply whether it agrees to be perceived; and obtaining the perception notification feedback according to a response message to the perception notification request.

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

[0049] Optionally, the service request also includes the location information of the terminal and / or the time information of the perception 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 request, for example.

[0050] The time information of the perception request is used to indicate one or more of the following: the time when the first communication device initiates the perception request, the time when the second communication device receives the perception request, the time of the perception request indicated by the perception request, or the time when the data management function network element receives the service request request. This time information can be carried in the service request request, or can be determined by the data management function network element based on the time when the service request request is received. This application does not limit this.

[0051] By carrying the location information of the terminal and / or the time information of the perception request in the service requirement request, the determination of the target service requirement can be further determined in combination with the location information and / or the location information.

[0052] From the above, it is not difficult to see that the target service requirement can be determined based on one or more of the information elements (IE) and / or time information carried in the service requirement request. The information elements include one or more of the following: the perception authority subscribed by the terminal, the indication that the terminal allows perception, perception notification feedback, location information, the time when the perception request is initiated, or the time when the perception request is received.

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

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

[0055] That is, when it is determined that the terminal allows being sensed, the second communication device determines the target service requirement on its own.

[0056] Without distinguishing the location of the terminal and the time information of the perception request, the second communication device can directly determine the target service requirement if the terminal allows perception. However, this application is not limited thereto, and the second communication device can also determine the target service requirement based on the location of the terminal or the time information of the perception request.

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

[0058] In a specific implementation, the second communication device may determine the target service requirement based on a mapping relationship and the region to which the terminal's location belongs, where the mapping relationship includes a correspondence between at least one service requirement and at least one region. Alternatively, the second communication device may determine the target service requirement based on the time information of the request perceived by the mapping relationship, where the mapping relationship includes a correspondence between at least one service requirement and at least one time period. Alternatively, the second communication device may determine the target service requirement based on the time information of the request perceived by the terminal's location and the region to which the terminal belongs, where the mapping relationship includes a correspondence between at least one service requirement and at least one combination of a region and a time period.

[0059] Optionally, obtaining the target business requirements includes: determining the target business requirements based on the perception authority, perception notification feedback and mapping relationship signed by the terminal, the perception notification feedback indicates that the terminal responds to the perception notification request and agrees to be perceived or the terminal does not respond to the perception notification request, the perception notification request is used to request the terminal to reply whether it agrees to be perceived, and the mapping relationship includes the correspondence between at least one combination of perception authority and perception notification feedback and at least one business requirement.

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

[0061] It is understandable that if it is not determined whether the terminal allows perception, the target service requirement may not be obtained. At this time, the target service requirement can be regarded as a rejection of the perception request, or the rejection of the perception request can be regarded as a type of target service requirement.

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

[0063] Furthermore, in the above mapping relationship, each of the at least one combination of perception permissions and perception notification feedback can 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 based on the perception permissions subscribed to the terminal, perception notification feedback, and the mapping relationship includes: determining the target service requirement based on the perception permissions subscribed to the terminal, perception notification feedback, the region to which the terminal's location belongs, and the mapping relationship.

[0064] That is, the terminal may have different service requirements in different areas, and the second communication device may further determine the target service requirement in combination with the area to which the terminal is located.

[0065] Alternatively, in the above-mentioned mapping relationship, each of the at least one combination of perception permissions and perception notification feedback can 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 based on the perception permissions subscribed by the terminal, the perception notification feedback, and the mapping relationship includes: determining the target service requirement based on the perception permissions subscribed by the terminal, the perception notification feedback, the time information of the perception request, and the mapping relationship.

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

[0067] That is, the terminal may have different service requirements in different time periods, and the second communication device may further determine the target service requirements based on the time when the perception request is initiated or received or the time period to which the perception request belongs.

[0068] In summary, it can be seen that the target service requirement can be determined based on one or more of the terminal's perception authority, perception notification feedback, terminal location, or time information. In other words, the target service requirement can be determined based on a mapping relationship, which can include a correspondence between at least one service requirement and at least one combination of one or more of the following: the terminal's contracted perception authority, perception notification feedback, region, or time period.

[0069] Through the various possible implementation methods of determining the target business requirements provided above, it can be seen that whether the target business requirements are obtained when it is determined that the terminal allows to be perceived, or when the target business requirements are obtained when it is not determined that the terminal allows to be perceived, the target business requirements are related to the perception authority of the terminal. Specifically, whether the terminal allows to be perceived needs to be determined based on the perception authority signed by the terminal and / or the perception notification feedback of the terminal. Even if the target business requirements are obtained without determining whether the terminal allows to be perceived, the target business requirements still need to be determined based on the perception authority signed by the terminal and the perception notification feedback of the terminal. Therefore, in general, the target business requirements are related to the perception authority of the terminal.

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

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

[0072] That is, the mapping relationships corresponding to different terminals of the same service type may be the same or different.

[0073] The above-mentioned perception request also carries the identifier of the terminal requesting perception. The mapping relationship may be a group of mapping relationships corresponding to the terminal determined from at least one group of pre-configured mapping relationships corresponding to at least one terminal.

[0074] In one possible design, the above mapping relationship is preconfigured in the second communication device.

[0075] 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.

[0076] Defining the correspondence between different terminals and different business requirements at the terminal granularity can meet the security needs of different terminals.

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

[0078] That is, the mapping relationships corresponding to the same terminal and different service types may be the same or different.

[0079] The above-mentioned perception request further indicates the requested service type. The mapping relationship may be a group of mapping relationships corresponding to the requested service type determined from at least one group of pre-configured mapping relationships corresponding to at least one service type.

[0080] Defining the correspondence between different business types and different business requirements based on business type granularity can meet different business needs.

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

[0082] That is, the above mapping relationship may be a set of mapping relationships corresponding to the terminal and the requested service type, determined from a plurality of pre-configured mapping relationships corresponding to at least one terminal and at least one service type.

[0083] By defining the correspondence between different terminals and different business types and different business requirements, both the security needs of different terminals and different business needs are taken into account, so that perception requests can be responded to more flexibly.

[0084] In combination with the first aspect, in some possible implementations of the first aspect, the perception request comes from the first communication device, and the perception request also carries the requested business requirements. The method also includes: sending a business requirement confirmation request to the first communication device, the business requirement confirmation request is used to request the adoption of the target business requirement, which is different from the requested business requirement; receiving a business requirement confirmation reply from the first communication device, the business requirement confirmation reply indicating agreement or disagreement to adopt the target business requirement; in a case where the business requirement confirmation reply indicates agreement to adopt the target business requirement, initiating a perception process for the terminal based on the target business requirement; or, in a case where the business requirement confirmation reply indicates disagreement to adopt the target business requirement, sending a rejection message to the first communication device, the rejection message being used to reject the perception request.

[0085] If the target service requirement is different from the requested service requirement, the second communication device may further confirm with the first communication device whether to agree to adopt the target service requirement.

[0086] In a possible case, the sending the service requirement confirmation request to the first communication apparatus includes: sending the service requirement confirmation request to the first communication apparatus when the level of the target service requirement is lower than the requested service requirement.

[0087] That is, when the service requires downgrade, it is further confirmed with the first communication device whether the downgrade is agreed.

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

[0089] That is, if the service requires an upgrade, further confirmation is made with the first communication device as to whether the upgrade is agreed.

[0090] From the above, it can be seen that the determination of the target service requirement 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.

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

[0092] The terminal is not allowed to be sensed. The above description has been made in detail in conjunction with the terminal's perception permissions, so it will not be repeated here.

[0093] The rejection message and the rejection message sent by the second communication device when the first communication device disagrees with the target service requirement 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 one can be sent.

[0094] Furthermore, the rejection message carries the reason for rejecting the perception request.

[0095] Exemplarily, the reason for rejecting the perception request may be that the terminal does not allow perception, or the first communication device does not agree to adopt the target service requirement, etc., which are not listed here.

[0096] In a second aspect, a perception method is provided. The method can be applied to a data management function network element (such as a UDM). The execution subject of the method can be, for example, the data management function network element, or a component configured in the data management function network element, such as a processor, chip, or chip system, or a logic module or software capable of implementing all or part of the functions of the communication device. This application is not limited to this.

[0097] The method includes: receiving a service requirement request from a second communication device, the service requirement request being used to request acquisition of a target service requirement, the target service requirement being used to determine a KPI for perceiving a terminal; determining the target service requirement, the target service requirement being related to the perception authority of the terminal, the perception authority of the terminal being used to determine whether the terminal is allowed or not allowed to be perceived; and sending the target service requirement to the second communication device.

[0098] In this solution, the second communication device can be, for example, an SF network element or a perception server. The second communication device can request the target service requirements from the data management function network element. Because the data management function network element pre-stores the terminal's subscription data, such as the terminal's subscription perception permissions, and other information that can be used to determine the target service requirements, such as mapping relationships, the data management function network element can determine the target service requirements corresponding to the terminal and send them to the second communication device.

[0099] Optionally, the perception authority of the terminal includes: the perception authority subscribed by the terminal, the perception notification feedback of the terminal, or a result of whether the terminal is allowed to be perceived determined by the perception authority subscribed by the terminal and the perception notification feedback of the terminal.

[0100] The terminal's perception authority, the terminal's contracted perception authority, the terminal's perception notification feedback, and the result of whether the terminal is allowed to be perceived determined by the terminal's contracted perception authority and the terminal's perception notification feedback have been described in detail in the first aspect. Please refer to the relevant description in the first aspect and will not be repeated here.

[0101] Optionally, the target service requirement is related to the perception authority of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be perceived, or the target service requirement is determined according to the perception authority of the terminal.

[0102] Whether the terminal is allowed or not to be sensed is determined by the sensing authority of the terminal, or the sensing authority of the terminal. Therefore, in general, the target service requirements are related to the sensing authority of the terminal.

[0103] For instructions on target service requirements and terminal perception permissions, please refer to the relevant description in the first aspect and will not be repeated here.

[0104] In conjunction with the second aspect, in certain possible implementations, the service requirement request indicates that the terminal allows perception, and determining the target service requirement includes determining a default service requirement as the target service requirement. The default service requirement may be a preconfigured service requirement or a requested service requirement, which is not limited in this application.

[0105] That is to say, when the terminal allows being sensed, the target service requirement can be directly determined, which is relatively simple and convenient.

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

[0107] In other words, the data management function network element can determine the target service requirement based on the area to which the terminal location belongs and a mapping relationship, where the mapping relationship indicates the correspondence 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 based on one of the time information of the perception request or the time information of the service requirement request, and a mapping relationship, where the mapping relationship indicates the correspondence between at least one service requirement and at least one time period.

[0108] The location information indicates the terminal's location. The time information for the awareness request indicates the time when the first communication device initiates the awareness request or the time when the second communication device receives the awareness request. The time information for the service request indicates the time when the second communication device sends the service request or the time when the data management function network element receives the service request.

[0109] In combination with the second aspect, in some possible implementations, the business requirement request carries the terminal's perception notification feedback, which indicates that the terminal responds to the perception notification request and agrees to be perceived or that the terminal has not responded to the perception notification request, and the perception notification request is used to request the terminal to reply whether it agrees to be perceived; and determining the target business requirement includes: determining the target business requirement based on the terminal's perception authority, perception notification feedback and a mapping relationship, and the mapping relationship includes a correspondence between at least one combination of perception authority and perception notification feedback and at least one business requirement.

[0110] That is, even if it is not confirmed that the terminal allows perception, the target service requirements can still be determined. The data management function network element can determine the target service requirements based on the perception notification feedback and the perception rights subscribed by the terminal. The data management function network element can further determine the target service requirements after determining that the terminal allows perception, or it can directly determine the target service requirements based on the perception rights subscribed by the terminal and the perception notification feedback.

[0111] Optionally, the service requirement request also carries one or more of the following: location information, time information of the perception request, or time information of the service requirement request, and the perception request is used to request perception of the terminal; determining the target service requirement includes: determining the target service requirement based on the location of the terminal and / or the time information of the perception request.

[0112] For the relevant instructions about location information and time information, please refer to the above and will not be repeated here.

[0113] As can be seen from the above, the target service requirement can be determined based on one or more of the IE and / or time information carried in the service requirement request. The information element includes one or more of the following: an indication that the terminal allows perception, perception notification feedback, location information, the time when the perception request was initiated, or the time when the perception request was received.

[0114] In other words, the target service requirement can be determined based on one or more of the terminal's perception rights, perception notification feedback, the terminal's location, or time information. In other words, the target service requirement can be determined based on a mapping relationship, which can include a correspondence between at least one service requirement and at least one combination of one or more of the following: the terminal's contracted perception rights, perception notification feedback, region, or time period.

[0115] From the two possible implementation methods of determining the target business requirements provided above, it can be seen that the determination of the target business requirements is not only related to the perception authority of the terminal, but can also be determined in combination with the location and / or time information of the terminal, thereby providing richer business requirements for perception requests and meeting the security needs of the terminal.

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

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

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

[0119] The relevant contents regarding the mapping relationship and the correspondence between the terminal and / or the requested service type have been described in detail in the first aspect above. Please refer to the relevant description in the first aspect and will not be repeated here.

[0120] In combination with the second aspect, in some possible implementations of the second aspect, before receiving the service requirement request from the second communication device, the method also includes: receiving a perception authorization request, the perception authorization request is used to request authorization of the perception request, and the perception request is used to request perception of the terminal; according to the perception authority contracted by the terminal, sending a perception authorization reply, the perception authorization reply indicates authorization of the perception request, or denial of authorization of the perception request.

[0121] The data management function network element can initially screen perception requests based on the perception rights subscribed to the terminal, so that perception requests for terminals that do not allow perception are directly rejected without having to be sent to the second communication device. This can reduce the signaling overhead associated with subsequent perception requests to the second communication device, the processing overhead associated with the second communication device determining whether the terminal is permitted to be perceived, and the signaling overhead and processing overhead associated with obtaining target service requirements.

[0122] Optionally, the perception authorization reply indicates authorization of the perception request, and the perception authorization reply carries the perception authority subscribed by the terminal and / or a mapping relationship for determining target business requirements, and the target business requirements are used to determine the KPI for perceiving the terminal.

[0123] The data management function network element can, when determining that the perception request is authorized, forward the perception authority and / or mapping relationship signed by the terminal to the second communication device through the third communication device through the perception authorization reply. That is, the perception authorization reply and the perception request sent by the third communication device to the second communication device can be reused, thereby reducing signaling overhead.

[0124] Optionally, the perception authorization reply indicates a rejection of the perception request authorization, and the perception authorization reply indicates a reason for the rejection.

[0125] If the data management function network element determines that authorization for the perception request is denied, it also indicates the reason for the denial to the third communication device through the perception authorization reply, thereby facilitating the third communication device to provide the reason for the denial to the first communication device, for example, the reason for the denial is that the terminal is not allowed to be perceived. This can avoid the first communication device from initiating another perception request for the terminal, reducing signaling overhead.

[0126] In a third aspect, a perception method is provided. The 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 logic module or software capable of implementing all or part of the functions of the communication device. This application is not limited to this.

[0127] The method includes: receiving a perception authorization request, the perception authorization request is used to request authorization of a perception request, the perception request is used to request perception of a terminal; sending a perception authorization reply based on the perception authority signed by the terminal, the perception authorization reply indicating authorization of the perception request, or refusal to authorize the perception request.

[0128] In this solution, the data management function network element can initially screen perception requests based on the perception rights subscribed to the terminal. This allows perception requests from terminals that do not allow perception to be directly rejected without having to be sent to the second communication device. This reduces the signaling overhead associated with subsequent perception requests to the second communication device, the processing overhead associated with the second communication device determining whether the terminal is permitted to be perceived, and the signaling overhead and processing overhead associated with obtaining target service requirements.

[0129] In combination with the third aspect, in some possible implementations, the perception authorization reply indicates the authorization of the perception request, and the perception authorization reply carries the perception authority signed by the terminal and / or a mapping relationship for determining the target business requirements, and the target business requirements are used to determine the KPI for perceiving the terminal.

[0130] The data management function network element can, when determining that the perception request is authorized, forward the perception authority and / or mapping relationship signed by the terminal to the second communication device through the third communication device through the perception authorization reply. That is, the perception authorization reply and the perception request sent by the third communication device to the second communication device can be reused, thereby reducing signaling overhead.

[0131] In conjunction with the third aspect, in some possible implementations, the perception authorization reply indicates a refusal to authorize the perception request, and the perception authorization reply indicates a reason for the refusal.

[0132] If the data management function network element determines that authorization for the perception request is denied, it also indicates the reason for the denial to the third communication device through the perception authorization reply, thereby facilitating the third communication device to provide the reason for the denial to the first communication device, for example, the reason for the denial is that the terminal is not allowed to be perceived. This can avoid the first communication device from initiating another perception request for the terminal, reducing signaling overhead.

[0133] In combination with the second aspect or the third aspect, in some possible implementation methods, the perception authority of the terminal contract includes one or more of the following: allowing perception, not allowing perception, allowing perception and requiring notification of the terminal but without the terminal replying, requiring notification of the terminal and allowing perception if the terminal replies in agreement or does not reply, or requiring notification of the terminal and allowing perception only if the terminal replies in agreement.

[0134] For relevant instructions on the perception authority of terminal contracts, please refer to the relevant description in the first aspect and will not be repeated here.

[0135] In a fourth aspect, a perception method is provided. The method can be applied to a first communication device. The first communication device can be, for example, an AF network element or an AS, or a server integrating AF and AS functions. It can also be a component configured in the AF network element, AS, or server, such as a processor, chip, or chip system. It can also be a logic module or software capable of implementing all or part of the functions of the first communication device. This application is not limited to this.

[0136] The method includes: receiving a service requirement confirmation request from a second communication device, the service requirement confirmation request being used to request adoption of a target service requirement, the target service requirement being different from the requested service requirement; and sending a service requirement confirmation reply to the second communication device, the service requirement confirmation reply indicating approval or disapproval of adoption of the target service requirement.

[0137] If the target service requirement differs 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. One possible implementation is to include the target service requirement in the service requirement confirmation request. The first communication device can determine whether to agree to adopt the target service requirement based on the target service requirement included in the service requirement confirmation request. Therefore, the determination of the target service requirement takes into account both the security requirements of the terminal and the needs of the first communication device, and can provide a better user experience.

[0138] In combination with the fourth aspect, in some possible implementations of the fourth aspect, the method further includes: receiving a rejection message from the second communication device, where the rejection message is used to reject the perception request.

[0139] It can be understood that the rejection message is sent by the first communication device when the service requirement confirmation reply indicates that the target service requirement is not accepted.

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

[0141] Illustratively, the reason for rejection is that the first communication device does not agree to adopt the target service requirement.

[0142] In a fifth aspect, a perception method is provided, which can be applied to a system including a data management function network element and a second communication device.

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

[0144] In combination with the fifth aspect, in some possible implementations, the second communication device obtains the target service requirements from the data management function network element, including: the second communication device sends a service requirement request to the data management function network element when determining that the terminal is allowed to be perceived, and the service requirement request indicates that the terminal is allowed to be perceived; the data management function network element determines the target service requirements; the data management function network element sends the target service requirements to the second communication device.

[0145] Optionally, the target service requirement carries one or more of the following: location information, time information of the perception request or time information of the service requirement, and the perception request is used to request perception of the terminal; the data management function network element determines the target service requirement, including: the data management function network element determines the target service requirement based on the target service requirement.

[0146] In a specific implementation, the data management function network element may determine the target service requirement based on the area to which the terminal's location belongs and a mapping relationship, where the mapping relationship includes a correspondence between at least one service requirement and at least one area. Alternatively, the data management function network element may determine the target service requirement based on the time information of the perception request and / or the time information of the service requirement request, as well as a mapping relationship, where the mapping relationship includes a correspondence between at least one service requirement and at least one time period. Alternatively, the data management function network element may determine the target service requirement based on the area to which the terminal's location belongs, one or more of the time information of the perception request or the time information of the service requirement request, as well as a mapping relationship, where the mapping relationship includes a correspondence between at least one service requirement and at least one combination of an area and a time period.

[0147] In combination with the fifth aspect, in some possible implementations, the method further includes: the second communication device determines that the terminal is allowed to be perceived.

[0148] Optionally, the second communication device determines that the terminal is allowed to be perceived, including: the second communication device determines that the terminal is allowed to be perceived based on the perception authority signed by the terminal and / or perception notification feedback, and the perception notification feedback indicates that the terminal replies to agree to be perceived or the terminal does not reply.

[0149] Optionally, the method further includes: the second communication device obtains the perception authority of the terminal contract from the data management function network element.

[0150] In combination with the fifth aspect, in some possible implementations, the second communication device obtains the target service requirements from the data management function network element, including: the second communication device sends a perception notification request to the terminal, and the perception notification request is used to request the terminal to reply whether it agrees to be perceived; the second communication device obtains perception notification feedback based on the response message of the perception notification request, and the perception notification feedback indicates that the terminal replies that it agrees to be perceived or the terminal does not reply; the second communication device sends a service requirement request to the data management function network element, and the service requirement request carries the perception notification feedback; the data management function network element determines the target service requirements; the data management function network element sends the target service requirements to the second communication device.

[0151] Optionally, the data management function network element determines the target business requirements, including: the data management function network element determines the target business requirements based on a mapping relationship, the mapping relationship including a correspondence between at least one business requirement and at least one combination of one or more of the following: perception authority of the terminal contract, perception notification feedback, terminal location, time information of the perception request, or time information of the business requirement request.

[0152] In a sixth aspect, a communication device is provided that can implement the sensing method described in aspects 1 to 4 and any possible implementation of aspects 1 to 4. The device includes one or more corresponding functional units or modules for performing the aforementioned method. The functional units or modules included in the device can be implemented in software and / or hardware.

[0153] In a seventh aspect, a communication device is provided, comprising a processor, wherein the processor is configured to execute the perception method described in the first to fourth aspects and any possible implementation manner of the first to fourth aspects.

[0154] Optionally, the apparatus 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 methods described in the above aspects may be implemented.

[0155] Optionally, the apparatus may further include a communication interface, which is used for the apparatus 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.

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

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

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

[0159] The chip system can be composed of chips, or can include chips and other discrete devices.

[0160] In a ninth aspect, a communication system is provided, comprising one or more of the aforementioned first communication device, second communication device, or data management function network element. The second communication device may be used to implement the functions of the first aspect and any possible implementation of the first aspect, the data management function network element may be used to implement the functions of the second or third aspect and any possible implementation of the second or third aspect, and the first communication device may be used to implement the functions of the fourth aspect and any possible implementation of the fourth aspect.

[0161] Optionally, the communication system may be used to implement the method in the above-mentioned fifth aspect and any possible implementation manner of the fifth aspect.

[0162] In the tenth aspect, a computer-readable storage medium is provided, comprising a computer program, which, when executed on a computer, enables the computer to implement the method in the first to fifth aspects and any possible implementation of the first to fifth aspects.

[0163] In the eleventh aspect, a computer program product is provided, which includes: a computer program (also referred to as code, or instructions), which, when executed, enables a computer to execute the method in the first to fifth aspects and any possible implementation of the first to fifth aspects.

[0164] It should be understood that the fifth to eleventh aspects of the present application correspond to the technical solutions of the first to fourth aspects of the present application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation methods are similar and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0165] FIG1 is a schematic diagram of two possible architectures in a fifth generation (5G) network;

[0166] FIG2 is a schematic diagram of a network architecture based on a service-based architecture (SBA) according to an embodiment of the present application;

[0167] FIG3 is a schematic diagram of a base station performing a sensing operation;

[0168] Figure 4 is a schematic diagram of the parameters of perception accuracy and resolution;

[0169] FIG5 is a schematic flow chart of a sensing method provided in an embodiment of the present application;

[0170] FIG6 is another schematic flow chart of the sensing method provided in an embodiment of the present application;

[0171] FIG7 is another schematic flow chart of the sensing method provided in an embodiment of the present application;

[0172] FIG8 is another schematic flow chart of the sensing method provided in an embodiment of the present application;

[0173] FIG9 is another schematic flow chart of the sensing method provided in an embodiment of the present application;

[0174] FIG10 is a schematic block diagram of a communication device provided in an embodiment of the present application;

[0175] FIG11 is another schematic block diagram of a communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0176] The technical solution provided in this application will be described below in conjunction with the accompanying drawings.

[0177] The method provided in this application can be applied to various communication systems, such as: long term evolution (LTE) system, LTE frequency division duplex (FDD) system, LTE time division duplex (TDD) system, 5G mobile communication system or new radio access technology (NR). Among them, the 5G mobile communication system can include non-standalone (NSA) and / or standalone (SA) networking.

[0178] The technical solution provided in 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 Internet of Vehicles. Among them, the communication mode in the Internet of Vehicles system is collectively referred to as vehicle to other devices (vehicle to X, V2X, 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.

[0179] The technical solution provided in this application can also be applied to future communication systems, such as the sixth generation (6G) mobile communication system, etc. This application does not limit this.

[0180] For ease of understanding, the network architecture applicable to the method provided in the embodiment of the present application is first described in more detail with reference to the accompanying drawings.

[0181] Figures 1a) and 1b respectively illustrate two possible architectures in a 5G network: a converged architecture (see Figure 1a)) and a standalone architecture (see Figure 1b)). The difference between the converged and standalone architectures lies in the location of the service-specific SF deployment.

[0182] As shown in Figure 1 (a), in a converged architecture, the SF can be deployed within the traditional 5G core network (5GC) and connected to other network elements using a serving-based architecture and SBA interface. A more detailed description of the SBA can be found in Figure 2 and will not be discussed here. The SF is connected to the NEF and can interact with servers outside the 5GC through the NEF, such as receiving perception request messages from external servers. The SF can also be connected to the UPF, allowing RAN devices such as base stations to send received perception data to the SF via the user plane for processing.

[0183] As shown in Figure 1 (b), in a standalone architecture, the SF can be deployed outside the traditional 5GC. The SF cannot connect to other network elements using the SBA interface and may need to interact with other 5GC network elements through an NEF (such as NEF 1 in the figure). Alternatively, the SF can connect to an NEF (such as NEF 2 in the figure) to interact with external servers through the NEF. Alternatively, the SF can interact directly with external servers without intermediating the NEF. Alternatively, the SF can connect to RAN equipment to interact with terminal devices.

[0184] It should be understood that the two possible architectures shown in a) and b) of Figure 1 are merely examples of the 5GC architecture and should not constitute any limitation on the present application. The method provided in this application is not limited to use in the two architectures shown in Figure 1.

[0185] Figure 2 is a schematic diagram of the network architecture of SBA in a 5G network provided by an embodiment of the present application. As shown in Figure 2, the 5G network architecture may include three parts: terminals, data networks (DNs), and operator networks.

[0186] The following is a brief description of the network elements involved in Figures 1 and 2.

[0187] A terminal may also be referred to as user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal device, wireless communication device, user agent or user device.

[0188] A terminal is a device with wireless transceiver capabilities. It communicates with one or more core network (CN) devices (also called core devices) via access network equipment (also called access devices) within a wireless access network. Terminals can be deployed on land, indoors or outdoors, handheld or in vehicles; on water (such as ships); or in the air (such as aircraft, balloons, and satellites).

[0189] A terminal can also be a terminal in the Internet of Things (IoT) system, also known as an IoT node. IoT is a crucial component of future information technology development. Its primary technical feature is connecting objects to the Internet through communication technologies, thereby enabling intelligent networks that interconnect humans and machines, and objects and things. Connections can be achieved through broadband or narrowband (NB) technology. IoT technology, for example, utilizes narrowband technology to achieve massive connections, deep coverage, and power-saving terminals.

[0190] In the embodiments of the present application, the device for implementing the functions of the terminal may be a terminal, or a device capable of supporting the terminal in implementing the functions, such as a chip system, which may be installed in the terminal or used in conjunction with the terminal. In the embodiments of the present application, the chip system may be composed of a chip, or may include a chip and other discrete devices. In the embodiments of the present application, only the terminal is used as an example to illustrate the device for implementing the functions of the terminal, and the embodiments of the present application are not limited to the solutions of the embodiments of the present application.

[0191] The terminal in this application can be a hardware device, a software function running on dedicated hardware, a software function running on general-purpose hardware, or a virtualized device, for example, implemented by general-purpose hardware and instantiated virtualization functions, or by dedicated hardware and instantiated virtualization functions. The general-purpose hardware can be a server, such as a cloud server.

[0192] The operator network may include one or more of the following network elements: authentication server function (AUSF) network element, network explosure 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 module (SMF) network element, user plain function (UPF) network element, network slice selection function (NSSF) network element, and access network (AN) (such as radio access network (RAN) network element). In the above-mentioned operator network, the part other than the RAN network element can be called the core network part. For the sake of convenience, the term "network element" is omitted in the following text. For example, AF network element is abbreviated as AF, UDM network element is abbreviated as UDM, SF network element is abbreviated as SF, and so on.

[0193] The RAN is a network consisting of multiple RAN nodes that implements radio physical layer functions, resource scheduling and radio resource management, radio access control, and mobility management. The 5G-RAN connects to the user plane function (UPF) via the user plane interface (N3) to transmit data from terminal devices. The 5G-RAN establishes a control plane signaling connection with the access and mobility management function (AMF) via the control plane interface (N2) to implement functions such as radio access bearer control.

[0194] RAN nodes provide wireless communication services and connect terminals to wireless networks. RAN nodes can also be called RAN devices or access network devices.

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

[0196] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, and different RAN nodes respectively implement part of the functions of the base station. For example, the RAN node can be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU and DU can be set separately, or they can 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 a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0197] In different systems, 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 access network (open RAN, O-RAN or ORAN) system, CU may also be called open CU (O-CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of 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.

[0198] In the embodiments of the present application, the device for implementing the functions of a RAN node may be the RAN node itself; or it may be a device capable of supporting the RAN node in implementing the functions, such as a chip system, a hardware circuit, a software module, or a combination of a hardware circuit and a software module. The device may be installed in the RAN node or used in conjunction with the RAN node. The embodiments of the present application are described using the RAN node as an example, and do not limit the embodiments of the present application.

[0199] The RAN node in this application can be a hardware device, a software function running on dedicated hardware, a software function running on general-purpose hardware, or a virtualized device, for example, implemented by general-purpose hardware and instantiated virtualization functions, or by dedicated hardware and instantiated virtualization functions. The general-purpose hardware can be a server, such as a cloud server.

[0200] SF is mainly responsible for the related processing of perception services, such as determining the perception results based on the acquired perception data, such as whether there is an intrusion, or calculating the distance, direction, and position of the surrounding reflective objects in the perception area.

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

[0202] The SMF is primarily responsible for all control plane functions of terminal session management, including UPF selection, Internet Protocol (IP) address allocation, session quality of service (QoS) management, and obtaining PCC (policy and charging control) strategies (from PCF).

[0203] As the anchor point for protocol data unit (PDU) session connections, the UPF is responsible for filtering terminal data packets, data transmission / forwarding, rate control, and generating billing information.

[0204] UDR is mainly used to store user data, including contract data called by UDM, policy information called by PCF, structured data for capability exposure, and application data called by NEF.

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

[0206] NEF is used to connect other internal network elements of the core network and the application function (AF) network elements corresponding to the application server (AS) outside the core network to provide network open capabilities to AF, or provide information provided by AF to core network network elements.

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

[0208] The PCF mainly controls quality of service (QoS) and charging policies, provides configuration policy information to terminals, and provides policy information for managing and controlling terminals to network control plane elements (such as AMF and SMF).

[0209] The AF primarily communicates application-side requirements to the network and can be considered an application server or an application server proxy. The AF can interact with core network elements to provide services. For example, it can interact with the PCF to control service policies, interact with the NEF to obtain network capability information or provide application information to the network, and provide data network access point information to the PCF to generate routing information for data services.

[0210] DN mainly provides business services to users.

[0211] Each network element communicates through an interface. For example, the interface between the terminal and AMF is the N1 interface, the interface between the AN and AMF is the N2 interface, the interface between the AN and UPF is the N3 interface, the interface between the SMF and UPF is the N4 interface, and the interface between the UPF and DN is the N6 interface. Some network elements can communicate based on service-based interfaces, among which Nnssf, Nnef, Nnrf, Npcf, Nudm, Naf, Nusf, Namf, Npcf, and Nsf in Figure 1 are service-based service interfaces. Among them, the interface Nsf is only one possible name, and this application does not limit the name of the service-based interface corresponding to the SF.

[0212] The above description of the various network elements in the core network and the interfaces between them is merely illustrative and does not constitute any limitation on this application. Furthermore, the various network elements shown in the figure can be understood as network elements used to implement different functions in the core network, for example, they can be combined into network slices as needed. These core network elements can be independent devices or integrated into the same device to implement different functions. This application does not limit the specific form of these network elements.

[0213] It can be understood that the network elements used in future communication systems can be the above-mentioned network elements, or can be network elements with other names that have the same or similar functions. This application does not limit this.

[0214] In the embodiments of the present application, the apparatus for implementing each core network function may be a core network element corresponding to each function; or it may be a device capable of supporting the core network element in implementing its respective function, such as a chip system, hardware circuit, software module, or a combination of hardware circuit and software module. The apparatus may be installed in the core network element or used in conjunction with the core network element. The embodiments of the present application are described using the core network element as an example, and do not limit the embodiments of the present application.

[0215] The core network element in this application can be a hardware device, a software function running on dedicated hardware, a software function running on general-purpose hardware, or a virtualized device, for example, implemented by general-purpose hardware and instantiated virtualization functions, or by dedicated hardware and instantiated virtualization functions. The general-purpose hardware can be a server, such as a cloud server.

[0216] Currently, some base stations or terminals in the RAN possess electromagnetic wave sensing capabilities and can be used as sensing nodes. The implementation of sensing is similar to the principle of radar. Specifically, a transmitter (i.e., a sensing node) emits electromagnetic waves, which are reflected by the object to be sensed and then captured by a receiver. The receiver (i.e., a sensing node) further processes the reflected signal (referred to as raw sensing data) to generate sensing data, which can be used to generate sensing results.

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

[0218] Table A

[0219] Figure 3 is a schematic diagram of a base station performing a sensing operation. Figure 3 is an example of integrated sensing and communication (ISAC). The base station shown in Figure 3 can reuse the electromagnetic wave signals of the communication system for sensing. As shown in the figure, the resources used by the base station for communication and sensing can be time-division multiplexed (as shown in Figure 3) or space-division multiplexed. The base station can use electromagnetic wave signals for sensing and detection, and can also receive signals (reflected signals or echo signals) that are transmitted after reaching obstacles (i.e., detected targets) and obtain sensing data based on the echo signals. As shown in Figure 3, 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 signals to be transmitted. The base station can also perform analog-to-digital conversion, parallel-to-serial conversion, fast Fourier transform (FFT), serial-to-parallel conversion, demodulation, etc. on the received echo signals. The signal to be transmitted may also be sent to the radar processor, so that the radar processor can obtain sensing data based on the signal to be transmitted and the received echo signal (it should be understood that the echo signal here is the echo signal after the above processing). It should be understood that the processing performed by the base station on the signal to be transmitted and the received echo signal shown in Figure 3 is only an example and should not constitute any limitation to this application.

[0220] The sensing nodes in the communication system can sense and identify designated areas, objects or events, meeting the sensing needs in many aspects such as autonomous driving, safety supervision, family health, and weather monitoring. Specific examples are as follows:

[0221] 1. Autonomous Driving

[0222] In V2X and unmanned aerial vehicle (VAU) scenarios, for example, since the perception distance of vehicles or drones is short or non-line of sight (NLOS) paths cannot be perceived, dynamic maps can be generated based on perception data; for example, during the driving process of vehicles or drones, there may be traffic hazards such as the sudden appearance of pedestrians or non-motor vehicles, or pedestrians or non-motor vehicles are in blind spots. Dangerous events can be identified based on perception data and the vehicle or drone can be notified to perform emergency operations; for example, in vehicle or drone autonomous driving assistance, customized high-precision dynamic maps can be generated based on perception data to assist vehicles or drones in autonomous driving.

[0223] 2. Safety Supervision

[0224] In V2X and drone scenarios, it is possible to identify vehicles or drones driving in violation of regulations based on perception data, such as vehicles occupying emergency lanes or drones leaving their routes, and to issue real-time warnings.

[0225] In perimeter security scenarios, based on perception data, it is possible to detect situations such as foreign objects intruding into railway tracks or drones intruding into no-fly zones (such as airports), track illegal objects, and perform real-time emergency response.

[0226] 3. Family Health

[0227] For example, abnormal postures can be identified based on perception data, so that falls and other situations can be identified and timely alarms can be issued; for another example, physiological parameters such as human breathing or heartbeat can be obtained through perception data, so that abnormalities can be identified and timely alarms can be issued.

[0228] 4. Meteorological Monitoring

[0229] It can perceive and predict the environment, climate, weather changes, etc.

[0230] Figure 4 is a schematic diagram of parameters that influence perception accuracy and resolution. Using the Internet of Vehicles (IoV) scenario as an example, Figure 4 illustrates several parameters that influence perception KPIs: positioning accuracy (both vertical and horizontal), velocity accuracy (both vertical and horizontal), and resolution (both area and speed).

[0231] 1. Range resolution α: The ability to distinguish adjacent targets at distance, usually measured as the minimum resolvable distance interval, used to identify different vehicles.

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

[0233] 3. Angular 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): The FOV shown in Figure 4 is 120°. With this 120° FOV, the two-way blind spot on a 30-meter-wide two-way road is less than 18 meters, and the blind spot area ratio is less than 1%.

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

[0236] First, in this application, indications include explicit indications (also called direct indications) and implicit indications (also called indirect indications). Specifically, explicit indication information A refers to including information A; implicit indication information A refers to 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 refer to indicating information A through information B and preset rules.

[0237] Second, in this application, information C is used to determine information D, which includes both information D being determined solely based on information C and information D being determined based on information C and other information. Furthermore, information C can also be used to determine information D indirectly, for example, when 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 "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship, but it does not exclude the situation where the previous and next associated objects are in an "and" relationship. The specific meaning can be understood in conjunction with the context. "At least one of the following items" or similar expressions refers 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 mean: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, c can be single or multiple.

[0239] Fourth, in this application, prefixes such as "first" and "second" are used solely to distinguish between different items belonging to the same category and do not constrain the order, size, or quantity of the items. For example, "first communication device" and "second communication device" are simply different communication devices; there is no size or priority relationship between them.

[0240] Fifth, the "sending" and "receiving" in this application indicate the direction of signal transmission. For example, "sending information to the terminal" can be understood as the destination end of the information is the terminal, which can include direct sending through the air interface, and also include indirect sending through the air interface by other units or modules. "Receiving information from the terminal" can be understood as the source end of the information is the terminal, which can include direct receiving from the terminal through the air interface, and also include indirect receiving from the terminal through the air interface from other units or modules. "Sending" can also be understood as the "output" of the chip interface, and "receiving" can also be understood as the "input" of the chip interface.

[0241] Sixth, in the embodiments of the present application, "when", "if" and "if" all mean that the device will make corresponding processing under certain objective circumstances, which does not limit the time, and does not require the device to have a judgment action when it is implemented, nor does it mean that there are other limitations.

[0242] Seventh, in this application, words such as "example," "exemplarily," "for example," or "such as" are used to indicate examples, illustrations, or explanations. Any embodiment or design described in this application as "example," "exemplarily," "for example," or "such as" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "example," "exemplarily," "for example," or "such as" is intended to present the relevant concepts in a concrete manner.

[0243] Eighth, in this application, a variety of message names are introduced, such as perception request, perception authorization request, perception authorization reply, service requirement request, service requirement reply, perception 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 correspondences shown in the tables of this application are merely examples and should not constitute any limitation on this application. The contents in each table are merely examples and can be configured as other contents, which are not limited by this application. When configuring these correspondences, it is not necessarily required to configure all the correspondences illustrated in each table. For example, the correspondences shown in certain rows may not be configured. For another example, certain columns may also be replaced with other forms. For another example, appropriate deformation adjustments may be made based on the tables shown in this document, such as splitting, merging, and the like.

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

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

[0247] In a perception request message for a specific service type or a specific terminal, the AF, AS, or terminal typically indicates service requirements. These service requirements can be used to describe the sender's requirements for the perception results, such as accuracy, resolution, latency, or refresh rate. Different terminals may have different security requirements. Some terminals may not want to expose their own information (such as location or movement speed) to the outside world, while others may not want to expose their own information to the outside world with high accuracy. The AF, AS, or terminal that initiates the perception request does not necessarily know in advance the security requirements of each terminal requesting perception. For reasons such as simplicity, the SF or perception server may directly initiate perception of the terminal based on the service requirements in the perception request message, but cannot flexibly and adaptively adjust the service requirements based on the different security requirements of the terminal, thereby failing to meet the different security requirements of different terminals. It is not difficult to see that there is currently no relevant security process for the perception process for specific terminals.

[0248] The present application provides a perception method, when the network element responsible for the perception function in the network (such as SF or perception service end) receives the perception request message for the terminal, it can obtain the service requirements (i.e., the target service requirements below) adopted for perceiving the terminal, and the service requirements are related to the perception authority of the terminal. As a result, the perception process initiated for the terminal is adapted to the perception authority of the terminal, rather than blindly determining the KPI for perceiving the terminal based on the service requirements requested by the AF network element or AS. In other words, the present application can obtain the target service requirements based on the terminal granularity. Specifically, the target service requirements of different terminals can be determined based on their corresponding perception authority. Therefore, taking into account the security needs of different terminals, different target service requirements are flexibly obtained based on the perception authority of different terminals, and then the perception process is initiated for different terminals based on different KPIs, rather than blindly using the same KPI to perceive all terminals requested for perception based on 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 following embodiments shown in combination with multiple drawings, the method provided by the present application is described using UDM as an example of a data management function network element, AF and AS as two examples of the first communication device, and SF and the perception server as two examples of the second communication device. These devices are only an example and should not constitute any limitation to the present application. 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 limit this.

[0251] Figure 5 is a schematic flow chart of the perception method provided in the present application. Figure 5 illustrates the method from the perspective of device interaction. As shown in Figure 5, the method 500 includes steps 501 to 513. The SF in Figure 5 can also be replaced by a component in the SF, such as a chip, a chip system or a processor, or can also be replaced by a logic module or software that can implement part or all of the functions of the SF; the UDM in Figure 5 can also be replaced by a component in the UDM, such as a chip, a chip system or a processor, or can also be replaced by a logic module or software that can implement part or all of the functions of the UDM; the AF in Figure 5 can also be replaced by a component in the AF, such as a chip, a chip system or a processor, or can also be replaced by a logic module or software that can implement part or all of the functions of the AF.

[0252] The various steps in method 500 are described in detail below.

[0253] In step 501, the AF sends a perception request to the NEF, where the perception request is used to request perception of the terminal.

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

[0255] 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 the communication system, the external identifier is used here to distinguish it from the identifier of the terminal in the communication system.

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

[0257] The requested service type may be one or more of at least one predefined service type. The at least one service type may include, but is not limited to, drone intrusion detection, autonomous driving, security monitoring, home health, or weather monitoring, etc., and the present application includes but is not limited to these.

[0258] The business requirements of a request can be used to describe the requirements for the requested perception results. For example, the business requirements of a request may include one or more of the following: perception location accuracy, perception velocity accuracy, perception resolution, or perception duration. The business requirements can be used to determine the KPIs corresponding to the perception results requested in the perception request.

[0259] For example, the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 22.173 defines the following perception KPIs: confidence interval, perception positioning accuracy (including vertical and horizontal), perception velocity accuracy (including vertical and horizontal), perception resolution (including area and speed), maximum perception service latency, and refresh rate. These parameters can be used to describe the required accuracy of perception data.

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

[0261] The time information of requesting perception may be used to request the time of perception. The time of requesting perception may specifically refer to the time of requesting perception of the terminal, or the time of requesting to initiate a perception process for the terminal.

[0262] As shown in the architectures shown in Figure 1 (a) and (b) above, the SF may be deployed in a converged architecture or an independent architecture. The AF may send the sensing request to the SF via the NEF. Therefore, in step 501, the NEF receives the sensing request from the AF.

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

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

[0265] In 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] In step 5022, the UDM determines whether the terminal is allowed to be sensed or not based on the sensing rights subscribed by the terminal.

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

[0268] The perception authorization request may, for example, carry the information in the above-mentioned perception request, such as the external identifier of the terminal and one or more of the following: the identifier of the AF, the requested service type, the requested service requirement, or the time information of the requested perception. In one possible design, the perception authorization request may be the above-mentioned perception request. In another possible design, the perception authorization request is obtained by processing the above-mentioned perception request. This application does not limit this.

[0269] The UDM can determine whether the terminal allows or does not allow perception (i.e., whether the terminal allows perception) based on the perception rights signed by the terminal, and indicate authorization or rejection of the perception request through a perception authorization reply. When the UDM determines that the terminal allows perception, it can indicate authorization of the perception request through a perception authorization reply, as shown in 5023a in the figure; when the UDM determines that the terminal does not allow perception, it can indicate rejection of authorization of the perception request through a perception authorization reply, as shown in 5023b in the figure. It can be understood that 5023a and 5023b can be regarded as two possible situations of step 5023, and one can be executed.

[0270] It can be understood that when the perception authorization reply indicates authorization of the perception request, the perception authorization reply can also be called an authorization message; when the perception authorization reply indicates refusal to authorize the perception request, the perception authorization reply can also be called a refusal authorization message.

[0271] Among them, the perception authority signed by the terminal is the perception authority signed by the terminal and the network operator, which can also be called the configured perception authority, or the default perception authority, or the perception authority stored on the network side. For example, the terminal can clarify whether it allows itself to be perceived by signing a contract with the operator. The perception authority signed by the terminal can be pre-configured in the UDM, for example, it can be manually stored in the UDM, or sent to the UDM in advance by the AF. This application does not limit this.

[0272] Exemplarily, the perception authority contracted by the terminal may include one of the following multiple authorities: allowing perception, not allowing perception, allowing perception and requiring notification of the terminal but not requiring a terminal reply, requiring notification of the terminal and allowing perception when the terminal replies in agreement or does not reply, or requiring notification of the terminal and allowing perception only when the terminal replies in agreement. Among them, "requiring notification of the terminal and allowing perception when the terminal replies in agreement or does not reply" specifically means: requiring notification of the terminal, allowing perception when the terminal replies in agreement or does not reply, and not allowing perception when the terminal replies in disagreement; "requiring notification of the terminal and allowing perception only when the terminal replies in agreement" specifically means: requiring notification of the terminal, allowing perception when the terminal replies in agreement or does not reply, and not allowing perception when the terminal replies in disagreement.

[0273] Table 1 shows several possible permissions.

[0274] Table 1

[0275] For each terminal, the perception authority it has signed a contract for is one of the multiple authorities shown in Table 1. Alternatively, the perception authority signed by the terminal may include one of the following multiple authorities: allowing perception, not allowing perception, allowing perception and requiring notification of the terminal but not requiring a terminal reply, requiring notification of the terminal and not allowing perception when the terminal replies with disagreement or no reply, or requiring notification of the terminal and not allowing perception only when the terminal replies with disagreement. Among them, "requiring notification of the terminal and not allowing perception when the terminal replies with disagreement or no reply" specifically means: requiring notification of the terminal and not allowing perception when the terminal replies with disagreement or the terminal does not reply; "requiring notification of the terminal and not allowing perception only when the terminal replies with disagreement" specifically means: requiring notification of the terminal and allowing perception when the terminal replies with agreement or no reply, and not allowing perception when the terminal replies with disagreement. The perception authority signed by each terminal may also be one of multiple authorities.

[0276] The perception rights signed by each terminal can be pre-configured in the UDM, for example, by indicating the terminal identifier and the index of the rights included in the perception rights signed by the terminal. For example, the perception rights signed by terminal 1 are to allow perception, the perception rights signed by terminal 2 are not to allow perception, the perception rights signed by terminal 3 are to allow perception, the terminal needs to be notified but no terminal reply is required, the perception rights signed by terminal 4 are to require notification of the terminal, and perception is allowed when the terminal replies in agreement or does not reply, and the perception rights signed by terminal 5 are to require notification of the terminal, and perception is allowed only when the terminal replies in agreement. The perception rights signed by the five terminals can be shown in Table 2.

[0277] Table 2

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

[0279] In step 5022, if the perception authority signed by the terminal is to allow perception, or to allow perception and need to notify the terminal but do not require the terminal to reply, then the UDM can directly determine that the terminal is allowed to be perceived and can authorize the perception request. If the perception authority signed by the terminal is not allowed to be perceived, then the UDM can directly determine that the terminal is not allowed to be perceived and can refuse to authorize the perception request. If the perception authority signed by the terminal is to need to notify the terminal and allow perception when the terminal replies in agreement or does not reply, or to need to notify the terminal and allow perception when the terminal does not reply, or to need to notify the terminal and allow perception only when the terminal replies in agreement, then the UDM cannot temporarily determine whether the terminal is allowed to be perceived, and needs to be determined in combination with the terminal's reply. At this time, the UDM can authorize the perception request in order to execute subsequent processes. It should be noted that the UDM's authorization of the perception request does not mean that the perception request will definitely be executed. Instead, it temporarily authorizes the perception request to facilitate the execution of subsequent processes, so that the determination of whether the terminal is allowed to be perceived is handed over to other network elements for execution. For example, in this embodiment, it is handed over to SF for execution. After receiving the perception request, SF can determine whether the terminal is allowed to be perceived, and obtain the target service requirements if it is determined that the terminal is allowed to be perceived, and reject the perception request if it is determined that the terminal is not allowed to be perceived. In other words, requesting the UDM to obtain authorization for the perception request can be regarded as the UDM's initial screening of the perception request, and it may not necessarily filter out all perception requests initiated for terminals that are not allowed to be perceived. For the sake of brevity, the description of the same or similar situations is omitted below.

[0280] Furthermore, the perception authority of the terminal contract may correspond to at least one area, and / or to at least one time period. In other words, the perception authority of the terminal contract includes at least one perception authority corresponding to at least one area, and / or, the perception authority of the terminal contract includes at least one perception authority corresponding to at least one time period. In other words, the perception authority of the terminal contract may vary depending on the location and / or time. For example, the perception authority of the terminal contract is different in area 1 and in area 2, or the perception authority of the terminal contract is different in time period A and in time period B, and so on. Exemplarily, the location may include one or more of the following: coordinate information, geographic area identifier, address information, tracking area identifier (TAI), or cell identifier (cell identifier, cell ID).

[0281] For example, Table 3 shows the correspondence between different permissions, different locations, and different times.

[0282] Table 3

[0283] For each terminal, its contracted perception rights include one or more of the multiple groups of correspondences shown in Table 3. In other words, the perception rights of a terminal can correspond to a specific area and / or a specific time period. Furthermore, a terminal can have the same or different perception rights in different areas and the same or different perception rights in different time periods.

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

[0285] If the perception permissions signed by the terminal include at least one perception permission corresponding to at least one area, since UDM cannot interact directly with the terminal, UDM may temporarily be unable to obtain the location of the terminal, and therefore temporarily cannot determine the perception permissions signed by the terminal, and may also be unable to determine whether the terminal is allowed to be perceived. Therefore, the perception request can be authorized to execute subsequent processes.

[0286] If the perception rights contracted by the terminal include at least one perception right corresponding to at least one time period, the UDM can determine the corresponding perception right based on the time period to which the perception request is received, and then determine whether the terminal is allowed to be perceived. Of course, the UDM may also need to determine it in combination with the terminal's reply. Therefore, if the time period to which the perception request belongs is within the range of at least one of the above time periods, and it is necessary to further determine the terminal's reply in combination with the terminal's permission to be perceived, the perception request can be authorized to execute the subsequent process.

[0287] In summary, UDM can initially screen sensing requests based on the sensing rights subscribed to the terminal, so that sensing requests from terminals that are not allowed to be sensed are directly rejected without having to be sent to the SF. This can reduce the signaling overhead of sending subsequent sensing requests to the SF, as well as the processing required by the SF to determine whether the terminal is allowed to be sensed and determine the target service requirements.

[0288] Optionally, when determining that the awareness request is authorized, the UDM may determine the identity of the terminal in the communication system based on the external identity of the terminal, such as the user permanent identifier (SUPI) of the terminal, and carry the SUPI of the terminal in the awareness authorization reply. In other words, the above-mentioned awareness authorization reply carries the SUPI of the terminal.

[0289] Optionally, the UDM may, when determining that the perception request is authorized, carry the perception authority signed by the terminal and / or the mapping relationship for determining the target business requirements in the perception authorization reply. In other words, the above-mentioned perception authorization reply carries the perception authority signed by the terminal and / or the mapping relationship for determining the target business requirements. Among them, the mapping relationship for determining the target business requirements may include one or more of the following: a correspondence between at least one business requirement and at least one time period, a correspondence between at least one business requirement and at least one area, or a correspondence between at least one business requirement and at least one combination of a time period and an area. Since the mapping relationship is described in detail in conjunction with the first mapping relationship, the second mapping relationship and the third mapping relationship in step 505 below, it will not be described in detail here. Optionally, the UDM may, when determining that the authorization for the perception request is rejected, carry the reason for rejection in the perception authorization reply. In other words, the above-mentioned perception authorization reply carries the reason for rejection. For example, the reason for rejecting the perception request is that the terminal is not allowed to be perceived.

[0290] In summary, the perception authorization reply (or, authorization message) indicates an authorization perception request and carries one or more of the following: the terminal's SUPI, the perception authority signed by the terminal, or a mapping relationship for determining the target service requirements, as shown in 5023a in the figure, or the perception authorization reply (or, authorization rejection message) indicates a rejection of the authorization perception request and indicates the reason for the rejection, as shown in 5023b in the figure.

[0291] The NEF may determine whether to continue sending the sensing request to the SF based on the received sensing authorization reply. If the sensing authorization reply indicates authorization of the sensing request, step 503 may be executed, and the NEF may send the sensing request to the SF. If the sensing authorization reply indicates rejection of the sensing request, step 504 may be executed, and the NEF may send a rejection message to the AF.

[0292] It should be noted that step 502 is not necessarily required. For example, in the independent architecture shown in FIG1 b), the NEF can directly forward the perception request to the SF without requesting authorization from the UDM. Even in the converged architecture shown in FIG1 a), the NEF can directly forward the perception request to the SF, and this application does not limit this.

[0293] In step 503, the NEF sends a sensing request to the SF.

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

[0295] Another possible implementation is that the NEF may 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.

[0296] If the NEF has obtained authorization from the UDM in step 502 before step 503, step 503 may be performed after receiving an authorization message from the UDM. For ease of understanding, it is assumed herein that the UDM determines that the terminal is allowed to be sensed and sends an authorization message to the NEF.

[0297] As mentioned above, the perception authorization reply can carry the SUPI of the terminal. The NEF can replace the external identifier of the terminal in the perception request received from the AF with the SUPI of the terminal based on the SUPI of the terminal carried in the perception authorization reply, and send the perception request replaced with the SUPI of the terminal to the SF. The perception authorization reply can also carry the perception authority subscribed by the terminal and / or the mapping relationship for determining the target service requirements. The NEF can also carry the perception authority and / or the mapping relationship for determining the target service requirements carried in the perception authorization reply in the perception request and send it to the SF. In this case, the perception request sent by the AF in step 501 can also be called the first perception request, and the perception request sent by the NEF in step 502 can be called the second perception request. It can be understood that both the first perception request and the second perception request can be used to request perception of the terminal. The difference is that the identifier of the terminal carried by the first perception request is the external identifier of the terminal, and the identifier of the terminal carried by the second perception request is the SUPI of the terminal, and the second perception request can also carry the perception authority and / or the mapping relationship for determining the target service requirements. That is, the second perception request carries the SUPI of the terminal, and one or more of the following: the identifier of the AF, the requested service type, the requested service requirement, the perception authority subscribed by the terminal, or a mapping relationship used to determine the target service requirement.

[0298] In summary, the perception request received by the SF in step 502 may be a first perception request or a second perception request. For the convenience of explanation, the first perception request and the second perception request are collectively referred to as perception requests.

[0299] Of course, the UDM may not carry the terminal's SUPI in the authorization message. In this case, the perception request sent by the NEF to the SF may be the perception request received from the AF, which is not limited in this application.

[0300] In addition, if authorization for the perception request is not obtained from the UDM before step 503 (for example, in an independent architecture as shown in FIG1 b , the NEF may directly forward the perception request to the SF without requesting authorization from the UDM, or the NEF directly forwards the perception request to the SF), the perception request sent by the NEF to the SF may also be the perception request received from the AF.

[0301] In step 504, the NEF sends a rejection message to the AF, where the rejection message is used to reject the sensing request.

[0302] As previously mentioned, if the NEF receives a Perception Authorization Response from the UDM indicating a rejection of the Perception Request authorization, it may send a rejection message to the AF to reject the Perception Request. Optionally, the rejection message may indicate the reason for rejecting the Perception Request. The reason for the rejection may be obtained from the Perception Authorization Response from the UDM or determined by the NEF itself, and this application does not limit this.

[0303] In one possible implementation, the NEF may forward the Awareness Authorization Reply received from the UDM directly to the AF. That is, the Awareness Authorization Reply and the Rejection message may be the same message. In another possible implementation, the NEF may generate a Rejection message based on the Awareness Authorization Reply received from the UDM. That is, the Awareness Authorization Reply and the Rejection message may be different messages. In step 505, the SF determines whether the terminal is permitted to be sensed.

[0304] In an embodiment of the present application, the target service requirement is related to the terminal's perception permission, including: the target service requirement is obtained when it is determined that the terminal is allowed to be perceived, and / or the target service requirement is determined based on the terminal's perception permission. This embodiment mainly provides a processing flow for obtaining the target service requirement when it is determined that the terminal is allowed to be perceived.

[0305] After receiving the perception request, the SF may first determine whether the terminal is allowed to be perceived or not (ie, whether the terminal is allowed to be perceived), and then obtain the target service requirements if the terminal is allowed to be perceived.

[0306] Whether the terminal is allowed or not to be sensed can be determined based on the sensing authority subscribed by the terminal and / or the sensing notification feedback of the terminal. The sensing authority subscribed by the terminal has been described in detail in step 502 above, and the relevant content above can be referred to and will not be repeated here.

[0307] One possible implementation method is that SF determines whether the terminal is allowed or not allowed to be perceived based on the perception authority signed by the terminal. If whether the terminal is allowed to be perceived does not need to be determined in combination with the terminal's reply (such as the perception notification feedback described in this article), for example, the perception authority signed by the terminal is not allowed to be perceived, or is allowed to be perceived, or is allowed to be perceived and the terminal needs to be notified but no terminal reply is required, then it can be directly determined whether the terminal is allowed to be perceived. The perception authority signed by the terminal can be obtained from UDM or pre-configured in SF, and this application does not limit this.

[0308] It can be understood that if the above step 502 has been executed, the UDM can determine whether the terminal is allowed to be sensed according to the sensing authority subscribed by the terminal, and step 505 does not need to be executed.

[0309] In addition, if the perception rights contracted by the terminal include at least one perception right 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 rights based on the area to which the terminal's location belongs, and then determine whether the terminal is allowed to be perceived.

[0310] For example, the SF may trigger the RAN node to initiate a positioning process for the terminal. The RAN node may send a reference signal to obtain the terminal's measurement data of the reference signal, such as the relative time of arrival (RTOA), angle of arrival (AOA), and reference signal received power (RSRP). The RAN node may determine the terminal's location based on this measurement data and report it to the SF. The specific implementation process of the terminal positioning process can be found in existing technologies and will not be described in detail herein.

[0311] Another possible implementation manner is that the SF may determine whether the terminal is allowed to be perceived according to the perception notification feedback of the terminal.

[0312] The perception notification feedback may indicate that the terminal agrees to be perceived, that the terminal disagrees to be perceived, or that the terminal does not respond. If the perception notification feedback indicates that the terminal agrees to be perceived, the SF may determine that the terminal allows perception; if the terminal disagrees to be perceived, the SF may determine that the terminal does not allow perception. If the terminal does not respond, the SF may determine whether the terminal allows perception based on preset rules (for example, the perception rights contracted by the terminal).

[0313] Another possible implementation is that the SF determines whether the terminal is allowed to be sensed based on the sensing authority subscribed by the terminal and the sensing notification feedback from the terminal.

[0314] For example, if the perception permission signed by the terminal requires notification of the terminal and allows perception when the terminal replies in agreement or does not reply, and the perception notification feedback of the terminal indicates that the terminal has not replied, it can be determined that the terminal allows perception.

[0315] For another example, the perception permission signed by the terminal requires notification of the terminal and is allowed to be perceived only when the terminal replies with consent, and the perception notification feedback of the terminal indicates that the terminal has not replied, then it can be determined that the terminal is not allowed to be perceived.

[0316] In some cases, although the terminal's contracted perception permission allows perception and requires notification of the terminal but does not require a response from the terminal, the terminal responds that it does not agree to perception. In this case, the terminal's perception notification feedback can be used as the primary factor to determine that the terminal does not allow perception. In other words, the terminal's perception notification feedback takes precedence over the priority of the terminal's contracted perception permission.

[0317] For the perception authority of the terminal contract, please refer to the relevant instructions above and I will not repeat them here.

[0318] Optionally, the method further includes step 506: the SF obtains perception notification feedback from the terminal.

[0319] The SF may obtain the terminal's perception notification feedback 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 506 specifically includes: the SF sending the perception notification request, and the SF obtaining the terminal's perception notification feedback from the response message to the perception notification request.

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

[0321] Step 5061: SF sends a perception notification request to AMF.

[0322] Step 5062: AMF forwards the perception notification request to the terminal to obtain a response from the terminal.

[0323] In step 5063, the AMF sends a response message of the perception notification request to the SF, where the response message of the perception notification request indicates whether the terminal replies that it agrees to be perceived, whether the terminal replies that it disagrees to be perceived, or whether the terminal does not reply.

[0324] Step 5064: SF obtains the perception notification feedback according to the response message of the perception notification request.

[0325] Exemplarily, the Awareness Notification Request carries an Awareness Request, or carries the SUPI of the terminal and one or more of the following: the AF ID, the requested service requirement, or the requested service type. Furthermore, the Awareness Notification Request is further used to instruct the AMF to reply to the Awareness Notification Feedback.

[0326] The response message to the awareness notification request may be a response message to the awareness notification request, and may be used to indicate the awareness notification feedback. A possible design is that the response message to the awareness notification request carries the awareness notification feedback.

[0327] 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 node. The AMF can also indicate the terminal's perception notification feedback 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.

[0328] 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, and does not necessarily mean that the terminal will respond. The terminal's perception notification feedback can be understood as the AMF's response to the perception notification request, combined with the terminal's response and the content of the response.

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

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

[0331] 2) The sensing permission signed by the terminal is to allow sensing, which requires the terminal to be notified but does not require the terminal to respond. The terminal does not respond;

[0332] 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;

[0333] 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;

[0334] 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.

[0335] In contrast, there are several possible situations where the terminal does not allow detection:

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

[0337] 2) The terminal needs to be notified, and the terminal is allowed to be sensed if it responds with consent or does not respond, and the terminal's perception notification feedback indicates that the terminal responds with disapproval of being sensed;

[0338] 3) 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 disagreement or the terminal's perception notification feedback indicates that the terminal has not responded;

[0339] 4) The terminal does not have the contracted perception authority, but the perception notification feedback of the terminal indicates that the terminal responds that it does not agree to be perceived;

[0340] 5) The sensing permission signed by the terminal is to allow sensing. The terminal needs to be notified but does not need to respond. However, the terminal responds that it does not agree to be sensed.

[0341] The above describes various possible implementations of determining whether a terminal is allowed to be sensed, in combination with various possible permissions and multiple examples. These examples are provided for ease of understanding only and should not constitute any limitation to this application.

[0342] In addition, the perception authority of the terminal contract can be pre-stored in the SF or obtained by the SF from the UDM.

[0343] Optionally, the method further includes: step 507, SF obtains the perception authority of the terminal contract from the UDM.

[0344] The SF can determine, based on the received perception request, that the perception request is for a certain terminal, and can then request the UDM to obtain the perception authority contracted by the terminal.

[0345] As mentioned 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 based on the identifier of the AF. For example, an AF list can be pre-stored in the SF, and the AF list contains the identifiers of the AFs corresponding to the predefined agencies. The predefined agency can be understood as follows: the perception request from the predefined agency must be executed without confirming whether the terminal is allowed to be perceived. In other words, steps 508 to 510 can be skipped and steps 511 to 512 can be executed directly. 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 based on the agency list and the identifier of the AF carried in the perception request.

[0346] In addition, if the identifier of the terminal obtained by the SF in the awareness request received from the NEF is an external identifier instead of the SUPI, the SF may also obtain the SUPI of the terminal in step 507.

[0347] If the SF determines in step 505 that the terminal is allowed to be sensed, it may continue to execute some of the steps from step 508 to step 513; if the SF determines in step 505 that the terminal is not allowed to be sensed, it may execute step 513, and the SF sends a rejection message to the AF.

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

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

[0350] In a possible design, the SF may pre-store a service requirement, which may be referred to as a default service requirement. The SF may directly determine the target service requirement if the terminal allows it to be sensed.

[0351] In another possible design, the perception request may carry a requested service requirement, and the SF may determine the requested service requirement as the target service requirement if the terminal allows perception. Alternatively, the SF may define a default service requirement as the requested service requirement without pre-configuring the default service requirement.

[0352] In another possible design, the target service requirement may be determined based on the time information of the perception request and / or the location of the terminal. In other words, the SF may determine the target service requirement corresponding to the time information of the perception request and / or the location of the terminal.

[0353] In one example, the target service requirement may be determined based on time information of the sensing request.

[0354] The time information of the perception request may be used to indicate one or more of the following: the time when the AF initiates the perception request, the time when the SF receives the perception request, or the time of the perception request carried in the perception request.

[0355] SF can determine the time period based on the time information and further determine the target service requirements.

[0356] For example, the time indicated by the time information is nighttime rest time, such as 21:00-7:00. Since the user is in a resting state and does not want his privacy to be exposed, the target service requirement can be determined as a service requirement with lower perception accuracy.

[0357] As another example, the target service requirement may be determined according to the location of the terminal.

[0358] The location of the terminal may be acquired by the SF, and according to the location of the terminal, a target service requirement corresponding to the location may be determined.

[0359] For example, the terminal is located at the user's home, and the user may not want his privacy to be exposed. Therefore, the target service requirement can be determined as a service requirement with lower perception accuracy.

[0360] In another example, the target service requirement may be determined based on time information of the sensing request and the location of the terminal.

[0361] For example, the time indicated by the time information is during the morning or evening rush hour, such as 7:00-9:00, or 17:00-19:00, and the terminal is located on the highway. Since there are more terminals on the highway during the morning and evening rush hours, perception with higher perception accuracy may involve the leakage of some privacy or sensitive information. Therefore, the target business requirement can be determined as a business requirement with lower perception accuracy.

[0362] In summary, we can see that combining the time information of the perception request and / or the location of the terminal can effectively prevent the exposure of user privacy and reduce the leakage of sensitive information. It can not only meet the security needs of the terminal, but also effectively and flexibly provide network openness capabilities.

[0363] In one possible implementation, the target service requirements corresponding to the time information of the perception request and / or the location of the terminal can be defined by a mapping relationship. When determining the target service requirements based on the time information of the perception request and / or the location of the terminal, the mapping relationship can be combined to determine it.

[0364] Optionally, the mapping relationship may include a correspondence between at least one service requirement and at least one time period, which is hereinafter referred to as a first mapping relationship for the convenience of distinction and description. Table 4 shows an example of the first mapping relationship.

[0365] Table 4

[0366] Optionally, the mapping relationship may include a correspondence between at least one service requirement and at least one area, which is hereinafter referred to as a second mapping relationship for the convenience of distinction and description.

[0367] Table 5 shows an example of the second mapping relationship.

[0368] Table 5

[0369] Optionally, the mapping relationship may include a correspondence between at least one service requirement and at least one combination of a region and a time period, which is hereinafter referred to as a third mapping relationship for the convenience of distinction and description.

[0370] Table 6 shows an example of the third mapping relationship.

[0371] Table 6

[0372] It should be understood that the first mapping relationship to the third mapping relationship illustrated in Tables 4 to 6 above are only shown for ease of understanding and should not constitute any limitation to this application. The mapping relationship described above for determining the target business requirements 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, they may be in a table or other forms, such as an enumeration of different combinations. This application is not limited to this.

[0373] It can be understood that business requirements A and B in Table 4, and business requirements 1 and 2 in Tables 5 and 6 can all be regarded as examples of default business requirements. In other words, there can be one or more default business requirements, and this application does not limit this.

[0374] Corresponding to the mapping relationships listed above, one possible implementation method for the SF to determine the target service requirement based on the time information of the perception request is to determine the target service requirement based on the time information of the perception request and the first mapping relationship. That is, the SF can determine the target service requirement corresponding to the time information based on the first mapping relationship. For example, taking the time when the AF initiates the perception request as an example, the SF can determine the corresponding target service requirement based on the time period to which the time belongs and the first mapping relationship described above.

[0375] One possible implementation of the SF determining the target service requirement based on the terminal's location is to determine the target service requirement based on the terminal's location and the second mapping relationship. That is, the SF may determine the area to which the terminal's location belongs within the at least one area, and then determine the target service requirement corresponding to the area based on the second mapping relationship.

[0376] One possible implementation of the SF determining the target service requirement based on the time information of the sensing request and the terminal's location is to determine the target service requirement based on the time information of the sensing request, the terminal's location, and the mapping relationship. Specifically, the SF may determine the region to which the terminal's location belongs and the time period to which the time information belongs, and then determine the corresponding target service requirement based on the third mapping relationship.

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

[0378] The mapping relationship used to determine the target service requirement (e.g., 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 the UDM. Accordingly, in step 5071a, the SF can obtain the mapping relationship locally or from the UDM.

[0379] One possible implementation of the SF obtaining the mapping relationship locally is that the mapping relationship can be manually stored in the SF's memory, or the AF can send it to the SF in advance, and the SF stores the received mapping relationship in the memory. The SF obtaining the mapping relationship locally can specifically refer to obtaining the mapping relationship from the memory.

[0380] Several possible implementations of SF obtaining the mapping relationship from UDM are as follows: for example, in step 5023a, when UDM sends the perception authorization reply, it can carry the perception authority subscribed by the terminal and the mapping relationship, and then in step 503, NEF can send the perception authority subscribed by the terminal and the mapping relationship to SF through a perception request. At this time, SF can obtain the mapping relationship for determining the target service requirements through steps 5023a and 503. For another example, in step 507, SF can also obtain the mapping relationship while obtaining the perception authority subscribed by the terminal from UDM. At this time, SF can obtain the mapping relationship for determining the target service requirements through step 507. Of course, SF can also request the mapping relationship from UDM through additional signaling, which is not limited in this application.

[0381] Another possible implementation of step 508 is shown in step 508b: SF obtains target service requirements from UDM.

[0382] For example, step 508b may specifically include the following steps 5083b in step 5081b:

[0383] 5081b, SF sends a service request to UDM.

[0384] 5082b, the UDM determines the target business requirement based on the business requirement request.

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

[0386] In step 5081b, one possible scenario is that the service requirement request may be sent to the data management function network element after the SF determines that the terminal allows sensing. In other words, the sending of the service requirement request may be triggered by the condition that the terminal allows sensing. After receiving the service requirement request, the data management function network element may determine the target service requirement and send it to the SF. In other words, sending the service requirement request can be used to implicitly indicate that the terminal allows sensing. Upon receiving the service requirement request, the data management function network element may assume that the terminal allows sensing.

[0387] Another possible scenario is that the service requirement request may also be sent as a result of SF determining whether the terminal is allowed to be perceived, and the service requirement request may be used to indicate whether the terminal is allowed to be perceived or not. In other words, regardless of whether the terminal is allowed to be perceived, SF may send the service requirement request to the data management function network element. The data management function network element may first determine whether the terminal is allowed to be perceived based on the received service requirement request, and determine and send the target service requirement to SF if the terminal is allowed to be perceived, while it is not necessary to determine the target service requirement if the terminal is not allowed to be perceived. In other words, 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 is allowed to be perceived, and the UDM may determine the target service requirement based on the service requirement request.

[0388] In step 5082b, the UDM determines the target business requirement in a manner similar to the SF's determination of the target business requirement in the example above. A default business requirement may be determined as the target business requirement, or the requested business requirement may be determined as the target business requirement. If the UDM determines the default business requirement as the target business requirement, the UDM may have pre-stored the default business requirement, or the requested business requirement may be defined as the default business requirement.

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

[0390] The location information indicates the location of the terminal, and the location information can be carried in the service request, for example. The time information can be used to indicate one or more of the following: the time when the AF initiates the perception request, the time when the SF receives the perception request, the time of the perception request carried in the perception request, the time when the SF sends the service request request, or the time when the UDM receives the service request request. The time information (such as the time when the AF initiates the perception request, the time when the SF receives the perception request, the time of the perception request carried in the perception request, or the time when the SF sends the service request request) can be carried in the service request request, or can be determined based on the time when the UDM receives the service request request.

[0391] The UDM can determine the target service requirement based on the location information. That is, the UDM can determine the target service requirement based on the terminal's location. One possible implementation is that the UDM can determine the target service requirement based on the terminal's location and the first mapping relationship. The specific process of the UDM determining the target service requirement based on the terminal's location can be found in the description of the SF determining the target service requirement based on the terminal's location in step 508a above, and will not be repeated here.

[0392] The UDM can also determine the target service requirements based on time information. One possible implementation is for the UDM to determine the target service requirements based on the time information and the second mapping relationship. The specific process of the UDM determining the target service requirements based on time information can be found in the description of the SF determining the target service requirements based on time information in step 508a above, and will not be repeated here.

[0393] The UDM may also determine the target service requirement based on the location information and time information. One possible implementation is for the UDM to determine the target service requirement based on the terminal's location, time information, and the third mapping relationship. The specific process for the UDM to determine the target service requirement based on the location information and time information can be found in the description of the SF determining the target service requirement based on the location information and time information in step 508a above, and will not be repeated here.

[0394] In the implementation shown in step 508b, the UDM may be locally preconfigured with the mapping relationship described above for determining target service requirements. For example, the mapping relationship may be manually stored in the UDM's memory, or the AF may pre-send the mapping relationship to the UDM, which then stores the received mapping relationship in its memory. Although not shown in the figure, it is understood that the UDM may also retrieve the mapping relationship from local memory.

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

[0396] If the target service requirement differs from the requested service requirement, the SF may send a service requirement confirmation request to the AF. For example, after obtaining the target service requirement, the SF may compare it with the requested service requirement to determine whether the target service requirement is the same as the requested service requirement. Alternatively, after obtaining the perception notification feedback in step 5064, the SF may directly determine whether the service requirement needs to be adjusted, such as downgrading or upgrading, based on the perception notification feedback. In other words, it is determined that the target service requirement is different from the requested service requirement, and it is not necessary to determine this by comparing the target service requirement with the requested service requirement after obtaining the target service requirement.

[0397] Of course, if SF determines that the target business requirement is the same as the requested business requirement, or if SF determines that the requested business requirement does not need to be adjusted, or if SF directly determines the requested business requirement as the target business requirement, there is no need to execute steps 509 to 510, and steps 511 and 512 are directly executed.

[0398] The SF may carry the target service requirement in the service requirement confirmation request to request to adopt the target service requirement.

[0399] The SF may carry the target service requirement in the service requirement confirmation request, which is used to instruct the AF to execute the perception process using a service requirement different from that in the perception request, and to request the AF to confirm whether the target service requirement can be used to execute perception.

[0400] One possible scenario is that the level of the target business requirement is different from the level of the requested business requirement. For example, the level of the target business requirement is lower than the level of the requested business requirement. In this case, the business requirement confirmation request can be understood as a request for AF to confirm whether the execution-perceived business requirement can be downgraded or not. The business requirement confirmation request can also be called a downgrade confirmation request.

[0401] Another possible situation is that the level of the target business requirement is different from the level of the requested business requirement. For example, the level of the target business requirement is higher than the level of the requested business requirement. In this case, the business requirement confirmation request can be understood as a request for AF to confirm whether the execution-aware business requirement can be upgraded or not. The business requirement confirmation request can also be called an upgrade confirmation request.

[0402] It should be noted that the level of a business requirement can be determined based on the values ​​of the various indicators corresponding to the business requirement. The indicators corresponding to the business requirement can be included in the business requirement, can be indicated by the business requirement, or can be indicators in the KPI converted from the business requirement, and this application does not limit this.

[0403] Here are a few examples of the target service requirement's level being lower than the requested service requirement's level: For example, the target service requirement's corresponding indicator has a perceived location accuracy of 1m, while the requested service requirement's corresponding indicator has a perceived location accuracy of 1mm. Since 1mm accuracy is higher than 1m accuracy, the target service requirement's level can be considered lower than the requested service requirement's level. For another example, the target service requirement's corresponding indicator has a perceived resolution of 5m, while the requested service requirement's corresponding indicator has a perceived resolution of 1m. Since 1m perception resolution is higher than 5m perception resolution, the target service requirement's level can be considered lower than the requested service requirement's level. For another example, the target service requirement's corresponding indicator has a maximum perceived service delay of 0.5ms, while the requested service requirement's corresponding indicator has a maximum perceived service delay of 0.2ms. Since 0.2ms delay is shorter than 0.5ms delay, the target service requirement's level can be considered lower than the requested service requirement's level.

[0404] Here are a few examples of target service requirements where the level is higher than the requested service requirement: For example, the target service requirement's perceived location accuracy is 1mm, while the requested service requirement's perceived location accuracy is 1m. Since 1mm accuracy is higher than 1m accuracy, the target service requirement's level can be considered higher than the requested service requirement's level. For another example, the target service requirement's perceived resolution is 1m, while the requested service requirement's perceived resolution is 5m. Since 1m resolution is higher than 5m resolution, the target service requirement's level can be considered higher than the requested service requirement's level. For another example, the target service requirement's maximum perceived service delay is 0.2ms, while the requested service requirement's maximum perceived service delay is 0.5ms. Since 0.2ms delay is shorter than 0.5ms delay, the target service requirement's level can be considered higher than the requested service requirement's level.

[0405] Of course, if the target service requirement differs from the requested service requirement, the SF may initiate the terminal awareness process based on the target service requirement without confirming with the AF whether the target service requirement is adopted. For example, if the target service requirement is higher than the requested service requirement, the terminal awareness process may be initiated based on the target service requirement without confirming with the AF whether the target service requirement is adopted. In this case, the SF does not need to determine whether the target service requirement is the same as the requested service requirement. In other words, steps 508 to 510 are optional and do not have to be performed.

[0406] In step 510, the AF sends a service requirement confirmation reply to the SF, where the service requirement confirmation reply indicates whether or not to adopt the target service requirement.

[0407] AF can determine whether to agree to adopt the target business requirements based on factors such as business needs, and indicate to SF whether it agrees to adopt the target business requirements through a business requirement confirmation reply.

[0408] If the service requirement confirmation reply indicates that the target service requirement is agreed to be adopted, steps 511 and 512 may be executed; if the service requirement confirmation reply indicates that the target service requirement is not agreed to be adopted, step 513 may be executed.

[0409] In step 511, the SF initiates a perception process for the terminal based on the target service requirement.

[0410] Exemplarily, step 511 may specifically include the following steps 5111 to 5112:

[0411] 5111, SF determines the KPI for terminal perception based on target business requirements.

[0412] 5112, SF initiates a perception process for the terminal based on the KPI.

[0413] Among them, the target business requirements can be KPIs, or include KPIs, or can also include information used to determine KPIs, such as identifiers or parameters corresponding to KPIs, and so on. KPIs are used to describe the accuracy with which perception data needs to be acquired. Exemplarily, KPIs may include one or more of the following indicators: confidence interval, perception positioning accuracy (including vertical and horizontal), perception speed accuracy (including vertical and horizontal), perception resolution (including area and speed), maximum perception service delay or refresh rate. These indicators are only an example of KPIs, and this application does not limit the specific indicators included in KPIs.

[0414] If the target service requirement is a KPI or includes a KPI, the SF may directly obtain the KPI for perceiving the terminal based on the target service requirement, and then initiate a process of perceiving the terminal.

[0415] If the target service requirement includes information for determining a KPI, the SF may convert the target service requirement into a KPI. In other words, one possible implementation method for the SF to determine the KPI perceived by the terminal based on the target service requirement is to determine the target service requirement as the KPI perceived by the terminal. Another possible implementation method is to convert the target service requirement into a KPI perceived by the terminal.

[0416] In one possible implementation, the target service requirement may include an identifier corresponding to a KPI. Based on the identifier in the target service requirement, the Service Provider (SF) may convert the target service requirement into a KPI perceived by the terminal. In another possible implementation, the SF may pre-store a correspondence between at least one identifier and at least one KPI, where each KPI may include one or more indicators. Based on the identifier included in the target service requirement, the SF may search for the KPI corresponding to the identifier from the pre-stored correspondence.

[0417] In another possible implementation, the target service requirement may also include parameters corresponding to KPIs. The SF may convert the target service requirement into a KPI perceived by the terminal based on the parameters in the target service requirement. In one possible implementation, the SF pre-stores a correspondence between at least one set of parameters and at least one KPI. Each set of parameters may include one or more parameters, and each KPI may include one or more indicators. Based on the set of parameters included in the target service requirement, the SF may search for the KPI corresponding to the set of parameters from the pre-stored correspondence.

[0418] This conversion can be based on a predefined mapping between business requirements and KPIs. For example, if the target business requirement is a specific identifier, the SF has a predefined KPI corresponding to that identifier. Alternatively, the parameters in the perception requirement can be translated into KPI parameters. For example, if the parameters in the perception requirement correspond to the parameters in the KPI, the SF will determine the parameters in the perception requirement as the corresponding KPI parameters. The perception requirement can also be equivalent to the KPI, meaning that no translation by the SF is required.

[0419] After SF determines the KPI, it can initiate the terminal perception process based on the KPI.

[0420] Specifically, the SF initiates a perception process of the terminal, where the SF selects a specific perception node (transmitter and receiver) and instructs the perception node to use the KPI to send and receive perception signals to the terminal, and determines the perception result after obtaining the perception data.

[0421] Table 7 below illustrates six possible sensing modes, distinguishing between the transmitter and receiver of the sensing signal. Specifically, these modes are: RAN node self-transmitting and self-receiving, RAN node A transmitting and RAN node B receiving, RAN node transmitting and terminal receiving, terminal transmitting and RAN node receiving, terminal self-transmitting and self-receiving, and terminal A transmitting and terminal B receiving. As can be seen, the transmitter can be either a terminal or a RAN node, and the receiver can be either a terminal or a RAN node.

[0422] Table 7

[0423] In this embodiment, the SF may use one of the sensing modes to initiate a sensing process for the terminal. For example, the SF may determine the transmitter and receiver based on the selected sensing mode, and then indicate the above KPI to the transmitter and receiver.

[0424] The specific process of the SF initiating the perception process of the terminal can be found in the existing technology, and for the sake of brevity, it is not described in detail.

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

[0426] After completing the perception process of the terminal, the SF can send the perception result to the AF through network elements such as NEF or UPF.

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

[0428] If the SF determines in step 505 that the terminal is not allowed to be sensed, or receives in step 510 a service requirement confirmation reply indicating that it does not agree to adopt the target service requirement, it may send a rejection message to the AF through the NEF to reject the above-mentioned perception request.

[0429] Optionally, the rejection message indicates the reason for rejecting the perception request. For example, the reason for rejecting the perception request may be that the terminal does not allow perception, or the AF does not agree to adopt the target service requirement, etc., which are not listed here.

[0430] One possible implementation method is to indicate different reasons by using different reason values, and the rejection message carries the reason value, which is used to indicate the reason for rejecting the perception request.

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

[0432] Based on the above scheme, when SF receives a perception request, it can first determine whether the terminal is allowed to be perceived, and then obtain the target service requirements for determining the KPIs for perceiving the terminal if allowed, so that the perception process initiated for the terminal is adapted to the perception authority of the terminal, rather than blindly determining the KPIs for perceiving the terminal directly according to the service requirements requested by the AF network element or AS. In other words, the present application can obtain target service requirements at the terminal granularity. Therefore, taking into account the security needs of different terminals, it can flexibly respond to the security needs of different terminals, rather than blindly perceiving without distinguishing terminals based on the perception request of the AF. In addition, by pre-configuring the correspondence between service requirements and regions, time periods, service types, etc. for each terminal, SF can determine the target service requirements based on factors such as the terminal requested to be perceived, the location of the terminal, the time of the perception request, and the service type requested, so that the network can use different service requirements to perceive the terminal in different regions, different time periods, and different service types, thereby providing more flexible network openness.

[0433] The above description, combined with FIG5 , illustrates a possible flow of the method provided by this application. The steps shown in FIG5 are merely examples and do not necessarily require execution of all steps. For example, steps 503 and 504 may be performed alternatively, steps 511 to 512 and step 513 may be performed alternatively, steps 507a and 507b may be performed alternatively, and so on. The sequence numbers of the steps do not imply a specific order of execution; the order of execution of the steps should be determined by their functions and inherent logic.

[0434] Figure 6 is another schematic flow chart of the perception method provided in an embodiment of the present application. Unlike method 500 shown in Figure 5, method 600 shown in Figure 6 provides another processing logic for obtaining target business requirements. The following description focuses on the steps that differ from method 500. For the same steps and descriptions of the same terms as method 500, please refer to the relevant description of method 500 above and will not be repeated here.

[0435] As shown in Figure 6, the method 600 may include steps 601 to 611. The steps in the method 600 are described in detail below.

[0436] In step 601, the AF sends a perception request to the NEF, where the perception request is used to request perception of the terminal.

[0437] In step 602, the NEF obtains authorization for the awareness request from the UDM.

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

[0439] Step 6021: NEF sends a perception authorization request to UDM, where the perception authorization request is used to request UDM to authorize the perception request.

[0440] In step 6022, the UDM determines whether the terminal is allowed to be sensed or not based on the sensing rights subscribed by the terminal.

[0441] In step 6023, the UDM sends a perception authorization response to the NEF, where the perception authorization response is used to indicate authorization or rejection of the perception request.

[0442] In step 603, the NEF sends a sensing request to the SF.

[0443] In step 604, the NEF sends a rejection message to the AF, where the rejection message is used to reject the sensing request.

[0444] In step 605, the SF obtains the perception authority of the terminal contract.

[0445] The specific process of steps 601 to 605 is the same as that of steps 501 to 504 and step 506 in method 500. Please refer to the relevant description of steps 501 to 504 and step 507 in method 500 above, and no further details will be given.

[0446] In step 606, the SF obtains the terminal's perception notification feedback. The SF can obtain the terminal's perception notification feedback by sending a perception notification request. The perception notification request requests the terminal to respond whether it agrees to be perceived. Optionally, step 606 specifically includes: the SF sending the perception notification request; and the SF obtaining the terminal's perception notification feedback based on a response message to the perception notification request.

[0447] The figure shows a possible implementation of step 606 from the perspective of device interaction. Exemplarily, optionally, step 606 specifically includes the following steps 6061 to 6064:

[0448] Step 6061: SF sends a perception notification request to AMF.

[0449] In step 6062, the AMF forwards the perception notification request to the terminal to request a response from the terminal.

[0450] Step 6063: The SF receives a response message to the perception notification request, where the response message to the perception notification request indicates that the terminal replies that it agrees to be perceived, that it disagrees and does not perceive, or that the terminal has not replied.

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

[0452] The specific process of step 606 is similar to that of step 506 in method 500, and reference may be made to the relevant description of step 506 in method 500. Unlike method 500, the SF may obtain the target service requirements without determining whether the terminal allows sensing. Therefore, the SF does not need to first determine whether the terminal allows sensing, but may directly execute step 607.

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

[0454] In an embodiment of the present application, the target service requirement is related to the terminal's perception authority, including: the target service requirement is obtained when it is determined that the terminal allows perception, and / or the target service requirement is determined based on the terminal's perception authority. This embodiment mainly provides a processing flow for determining the target service requirement based on the terminal's perception authority.

[0455] 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 based on the terminal's sense notification feedback and / or the sense authority subscribed by the terminal.

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

[0457] The SF may determine the target service requirements based on the sensing rights subscribed by the terminal and / or the sensing notification feedback of the terminal. In other words, the SF may determine the target service requirements corresponding to the sensing rights subscribed by the terminal and / or the sensing notification feedback.

[0458] In one possible implementation, the target service requirements corresponding to the terminal's subscribed perception rights and / or the terminal's perception notification feedback can be defined by a mapping relationship. This mapping relationship indicates the correspondence between at least one service requirement and at least one combination of the terminal's subscribed perception rights and the terminal's perception notification feedback. The SF can determine the target service requirements based on the above mapping relationship and one or more of the terminal's subscribed perception rights or the terminal's perception notification feedback.

[0459] Optionally, the mapping relationship includes at least one combination of at least one service requirement, the perception authority contracted by the terminal, and the perception notification feedback, which is hereinafter referred to as the fourth mapping relationship for the sake of distinction and explanation.

[0460] For ease of understanding, Table 8 shows an example of the fourth mapping relationship.

[0461] Table 8

[0462] For each terminal, the fourth mapping relationship may include one of the multiple groups of corresponding relationships shown in Table 8.

[0463] As can be seen, in the fourth mapping relationship shown in Table 8, in the two sets of correspondences corresponding to indexes 1 and 2, the service requirements correspond to the perception permissions subscribed by the terminal. Therefore, the target service requirements can be determined based on the perception permissions subscribed by the terminal without combining them with the perception notification feedback. Although not shown in the figure, it is understood that the fourth mapping relationship can also include a correspondence between perception notification feedback and service requirements. In this case, the target service requirements can also be determined based on the perception notification feedback of the terminal without combining them with the perception permissions subscribed by the terminal.

[0464] Furthermore, the SF may further combine the terminal's location and / or time information to determine the target service requirements. In other words, the above mapping relationship includes a correspondence between at least one service requirement and at least one combination of one or more of the following: the terminal's contracted perception authority, the terminal's perception notification feedback, region, or time period.

[0465] Optionally, the mapping relationship includes at least one combination of the perception authority, perception notification feedback, and area for which at least one service requirement is contracted with the terminal. For ease of distinction and description, it is hereinafter referred to as the fifth mapping relationship.

[0466] For ease of understanding, Table 9 shows an example of the fifth mapping relationship.

[0467] Table 9

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

[0469] Optionally, the mapping relationship includes at least one combination of the perception authority, perception notification feedback and time period for which at least one service requirement is contracted with the terminal. For ease of distinction and description, it is hereinafter referred to as the sixth mapping relationship.

[0470] For ease of understanding, Table 10 shows an example of the sixth mapping relationship.

[0471] Table 10

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

[0473] Optionally, the mapping relationship includes at least one combination of the perception authority, perception notification feedback, time period and area contracted by the terminal for at least one service requirement, which is hereinafter referred to as the seventh mapping relationship for the sake of distinction and explanation.

[0474] For ease of understanding, Table 11 shows an example of the seventh mapping relationship.

[0475] Table 11

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

[0477] Furthermore, the fourth mapping relationship, the fifth mapping relationship, the sixth mapping relationship, and the seventh mapping relationship may also correspond to a service type. That is, the mapping relationships shown in Table 8, Table 9, Table 10, and Table 11 may be mapping relationships corresponding to a certain service type, and the fourth mapping relationship, the fifth mapping relationship, the sixth mapping relationship, and the seventh mapping relationship may also include mapping relationships corresponding to one or more other service types. For the sake of brevity, examples are not listed here. It is understood that if each of the above mapping relationships corresponds to a service type, the SF can determine the mapping relationship based on the requested service type indicated by the perception request, and then determine the target service requirements based on the mapping relationship.

[0478] In addition, service requirements 1 and 2 shown in Tables 8, 9, 10, and 11 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 a service requirement as the target service requirement based on the terminal's contracted perception permissions and perception notification feedback. For details about the levels of service requirements, please refer to the relevant description in step 509 of method 500 above and will not be repeated here.

[0479] For example, consider a scenario where default business requirements are divided into two levels (i.e., business requirement 1 and business requirement 2). One possible design is that both business requirement 1 and business requirement 2 can be preconfigured. Another possible design is that business requirement 1 is a requested business requirement, or that business requirement 1 does not require preconfiguration, while business requirement 2 is preconfigured. In this case, business requirement 1 can also be called a requested business requirement.

[0480] Business requirements 1 and 2 in the table are only examples. The default business requirements can also be divided into more levels, or not divided into levels. In this case, the fourth mapping relationship, fifth mapping relationship, sixth mapping relationship and seventh mapping relationship illustrated in Tables 8, 9, 10 and 11 respectively can also be adjusted accordingly. For the sake of brevity, examples are not listed here.

[0481] It is understandable that not distinguishing levels for default service requirements can make network-side processing simpler. Defining multiple levels for default service requirements allows the network to flexibly select service requirements based on different terminal perception notification feedback, thereby balancing the terminal's security needs with the AF's service needs and providing a better user experience.

[0482] It should also be noted that, since the SF does not predetermine whether the terminal allows perception in method 600, the terminal may reply that it does not agree to be perceived, that is, the terminal does not allow perception. Therefore, in the fourth mapping relationship, fifth mapping relationship, sixth mapping relationship, and seventh mapping relationship shown in Tables 8, 9, 10, and 11 above, respectively, the service requirements corresponding to some combinations of the perception permission subscribed by the terminal and the perception notification feedback can be defined as rejecting the perception request, or set to a predefined value (such as "0" or "NULL") to indicate the rejection of the perception request. These combinations may include: the perception permission subscribed by the terminal is "not allowed to be perceived", and the perception notification feedback is "N / A"; the perception permission subscribed by the terminal is "need to notify the terminal, and perception is allowed if the terminal replies with consent or no reply; need to notify the terminal, and perception is not allowed if the terminal replies with disagreement", and the perception notification feedback is "reply disagree to be perceived"; the perception permission subscribed by the terminal is "need to notify the terminal, and perception is not allowed if the terminal replies with disagreement or no reply; need to notify the terminal, and perception is allowed if the terminal replies with consent", and the perception notification feedback is "reply disagree to be perceived".

[0483] The following uses the fourth mapping relationship, the fifth mapping relationship, and the sixth mapping relationship as examples to illustrate the process of SF determining the target service requirements.

[0484] In one implementation, the SF determines the target service requirement according to the perception notification feedback of the terminal, the perception authority subscribed by the terminal, and the fourth mapping relationship.

[0485] Take the fourth mapping relationship shown in Table 8 as an example.

[0486] For example, if the sensing permission signed by the terminal is not allowed to be sensed, the SF may determine to reject the sensing request.

[0487] For another example, the sensing permission contracted by the terminal is: the terminal needs to be notified, and sensing is allowed when the terminal responds with consent or does not respond. If the terminal's sensing notification feedback indicates that the terminal has not responded, the SF may determine that the target service requirement is service requirement 2.

[0488] For another example, the sensing rights contracted by the terminal are: the terminal needs to be notified and is only allowed to be sensed if the terminal replies with consent. If the terminal's sensing notification feedback indicates that the terminal replies with consent to be sensed, the SF may determine that the target service requirement is service requirement 1.

[0489] In another implementation, the SF determines the target service requirement based on the terminal's perception notification feedback, the perception authority subscribed by the terminal, the terminal's location, and the fifth mapping relationship. The terminal's location can be obtained by initiating a positioning process for the terminal.

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

[0491] For example, the location of the terminal belongs to area 2, and the sensing permission subscribed by the terminal in area 2 is to allow sensing, and the SF may determine that the target service requirement is service requirement 1.

[0492] For example, if the terminal's location is in Area 4, the sensing rights subscribed by the terminal in Area 4 are: notification required, sensing permitted if the terminal responds with consent, or no response. If the terminal's sensing notification feedback indicates no response, the SF may determine that the target service requirement is Service Requirement 2.

[0493] In another implementation, the SF determines the target service requirement based on the terminal's perception notification feedback, the terminal's subscribed perception rights, the time information of the perception request, and the sixth mapping relationship. The terminal's location 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.

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

[0495] For example, the time when SF receives the perception request belongs to time period C, and the perception permission signed by the terminal in time period C is to allow perception, need to notify the terminal but do not need the terminal to reply, and SF can determine that the target business requirement is business requirement 1.

[0496] For example, if the SF receives the sensing request during time period E, the sensing rights of the terminal during time period E are: the terminal must be notified and sensing is permitted only if the terminal responds with consent. If the terminal does not respond, the SF may determine that the target service requirement is to reject the sensing request.

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

[0498] For example, the time when SF receives the perception request belongs to time period C, and the location of the terminal belongs to area 3. The perception permission signed by the terminal corresponding to time period C and area 3 is to allow perception, need to notify the terminal but do not require the terminal to reply. SF can determine that the target business requirement is business requirement 1.

[0499] For example, if the SF receives the sensing request during time period E and the terminal is located in area 5, the sensing rights contracted by the terminal for time period E and area 5 are: terminal notification required, and sensing permitted only if the terminal responds with consent. If the terminal does not respond, the SF may determine that the target service requirement is to deny the sensing request.

[0500] The above examples of the process of SF determining 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 8, Table 9, Table 10 and Table 11 are only examples and should not constitute any limitation to this application.

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

[0502] The mapping relationship can be configured in the SF or pre-configured in the UDM. Accordingly, the SF can obtain the mapping relationship locally or from the UDM.

[0503] One possible implementation of the SF obtaining the mapping relationship locally is that the mapping relationship can be manually stored in the SF's memory, or the AF can send it to the SF in advance, and the SF stores the received mapping relationship in the memory. The SF obtaining the mapping relationship locally can specifically refer to obtaining the mapping relationship from the memory.

[0504] Several possible implementations of SF obtaining the mapping relationship from UDM are as follows: For example, in step 6023a, when UDM sends the perception authorization reply, it can carry the perception authority subscribed by the terminal and the mapping relationship, and then in step 603, NEF can send the perception authority subscribed by the terminal and the mapping relationship to SF through a perception request. At this time, SF can obtain the mapping relationship for determining the target service requirements through steps 6023a and 603. For another example, in step 606, SF can also obtain the mapping relationship while obtaining the perception authority subscribed by the terminal from UDM. At this time, SF can obtain the mapping relationship for determining the target service requirements through step 605. Of course, SF can also request the mapping relationship from UDM through additional signaling, and this application does not limit this.

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

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

[0507] 6071b, SF sends a service request to UDM, and the service request carries the terminal's perception notification feedback.

[0508] 6072b, UDM determines the target business requirement based on the business requirement request.

[0509] 6073b, UDM sends the target service request to SF.

[0510] Unlike step 507b in method 500, the service requirement request sent by the SF to the UDM includes the terminal's perception notification feedback. In other words, the service requirement request is not necessarily sent when the terminal allows perception, and the service requirement request is not used to indicate that the terminal allows perception. The UDM can determine the target service requirement based on the terminal's perception notification feedback, the perception rights subscribed by the terminal, and the mapping relationship.

[0511] The specific process of UDM determining the target business requirements based on the perception notification feedback of the terminal, the perception authority signed by the terminal, and the mapping relationship is similar to the specific process of SF determining the target business requirements based on the perception notification feedback of the terminal, the perception authority signed by the terminal, and the mapping relationship. For example, it can be determined based on the perception notification feedback of the terminal, the perception authority signed by the terminal, and the fourth mapping relationship, or based on the perception notification feedback of the terminal, the perception authority signed 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 authority signed by the terminal, time information and the sixth mapping relationship. The 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 the perception request, or it can 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 the service requirement request, etc.

[0512] For more specific details about how the UDM determines the target service requirements based on the terminal's perception notification feedback, the perception authority subscribed by the terminal, and the mapping relationship, please refer to the relevant description of step 607a above, which will not be repeated here.

[0513] Of course, UDM can also determine whether the terminal allows or does not allow perception based on the perception authority and / or perception notification feedback signed by the terminal, and then determine the target business requirements when the terminal allows perception. In this case, UDM can adopt a similar method to step 607a to determine the target business requirements based on the perception authority and perception notification feedback signed by the terminal, and can also determine the target business requirements in combination with time information and / or location information; it can also adopt a method such as step 5082b of method 500 to determine the default business requirements as the target business requirements, or determine the requested business requirements as the target business requirements, or determine the target business requirements based on time information and / or location information. This application does not limit this.

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

[0515] In step 608, the SF sends a service requirement confirmation request to the AF, where the service requirement confirmation request is used to request to adopt the target service requirement.

[0516] In step 609, the AF sends a service requirement confirmation reply to the SF, where the service requirement confirmation reply indicates whether or not to adopt the target service requirement.

[0517] In step 610, the SF initiates a perception process for the terminal based on the target service requirement.

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

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

[0520] For the specific process of steps 608 to 612, please refer to the relevant description of steps 509 to 513 in the above method 500, which will not be repeated here.

[0521] It is understood that, if the target service requirement differs from the requested service requirement, the SF may initiate a terminal awareness process based on the target service requirement without confirming with the AF whether the target service requirement is adopted. In this case, the SF does not need to determine whether the target service requirement is the same as the requested service requirement. In other words, steps 609 to 610 are optional and do not have to be performed.

[0522] Based on the above solution, when the SF receives a perception request, it can first obtain the perception notification feedback of the terminal, and then obtain the target service requirements of the KPI used to perceive the terminal, so that the perception process initiated for the terminal is adapted to the perception authority of the terminal, rather than blindly determining the KPI for perception of the terminal based on the service requirements requested by the AF network element or AS. In other words, this application can be related to the perception authority of the terminal and obtain the target service requirements at the terminal granularity. Therefore, the network side takes into account the security needs of different terminals and flexibly responds to perception requests based on the security needs of different terminals, rather than blindly perceiving based on the AF perception request 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 requirements based on factors such as the terminal requested for perception, the location of the terminal, the time of the perception request, and the requested service type. This allows the network to use different service requirements to perceive the terminal in different regions, different time periods, and different service types, thereby providing more flexible network openness.

[0523] The above, combined with FIG6 , illustrates a possible flow of the method provided by this application. The steps shown in FIG5 are merely examples and do not necessarily require execution of all steps in FIG6 . For example, steps 603 and 604 may be performed alternatively, steps 610 to 611 and step 612 may be performed alternatively, steps 607a and 607b may be performed alternatively, and so on. The sequence numbers of the steps do not imply a specific order of execution; the order of execution of the steps should be determined by their functions and inherent logic.

[0524] As can be seen from the above methods combined with Figures 5 and 6, the target service requirements can be determined when the terminal allows perception, or can be determined based on the perception rights subscribed by the terminal and the perception notification feedback of the terminal. Whether the terminal allows or does not allow perception is determined based on the perception rights subscribed by the terminal and / or the perception notification feedback, and whether the terminal allows or does not allow perception can be indicated by the terminal's perception rights. Therefore, in general, the target service requirements are related to the perception rights of the terminal.

[0525] In the above description of the processes shown in FIG5 and FIG6, the perception method provided in the present application is described by taking the interaction between AF, NEF, UDM, SF and terminal as an example, but this should not constitute any limitation to the present application. In another possible architecture, the network side may include a perception server (or perception server), and the terminal may install a perception client (sensing client). The perception server can be understood as a perception service platform provided by the network at the upper layer of the protocol stack, and the perception client can be understood as a perception service platform located at the upper layer of the protocol stack in the UE. User-plane interaction can be achieved between the perception server and the perception client. The perception server can be regarded as a functional network element for connecting to external applications (such as AF or AS), and user-plane interaction can also be achieved between the perception server and the AS. Considering that the network can provide multiple perception functions, and the perception request of the application may involve multiple or multiple perception functions provided by the network, in order to avoid the external application (such as AF or AS) from splitting its perception request into multiple or multiple perception functions provided by the network for request, the network can use the perception server to proxy the perception request of the application with the multiple or multiple perception functions provided by the network. Specifically, the perception server is used to receive perception requirements from external applications (AF or AS), and further interact with the network and UE according to the perception requirements and feed back perception results.

[0526] In the embodiment of the present application, the perception server can be used to implement the SF portion of the process shown in Figure 5 or Figure 6, and the perception client can be used to implement the terminal function in the process shown in Figure 5 or Figure 6. For ease of understanding, the following is explained in conjunction with Figures 7 and 8.

[0527] Figure 7 is another schematic flowchart of the perception method provided in an embodiment of the present application. Figure 7 is similar to the processing flow of method 500 shown in Figure 5. For the same or similar steps and descriptions of the same terms in method 500, please refer to the relevant description of method 500 above and will not be repeated here.

[0528] As shown in Figure 7, the method 700 may include steps 701 to 713. Each step in the method 700 is described in detail below.

[0529] In step 701, the AS sends a first perception request to the perception server, where the first perception request is used to request perception of the terminal.

[0530] The AS can interact with the perception server on the user plane, so the first perception request is a user plane message. Exemplarily, the first perception request carries the external identifier of the terminal and one or more of the following: the identifier of the AS, the requested service requirement, or the requested service type.

[0531] The process of AS sending the first perception request to the perception server is similar to the process of AF sending the perception request to NEF in step 501 of the above method 500. Please refer to the relevant instructions in step 501 of the above method 500 and will not be repeated here.

[0532] In step 702, the awareness server obtains authorization for the awareness request from the UDM.

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

[0534] In step 7021, the perception server sends a perception authorization request to the UDM, where the perception authorization request is used to request the UDM to authorize the first perception request, or to request the UDM to perform an authorization check on the first perception request.

[0535] In step 7022, the UDM determines whether the terminal is allowed to be sensed or not based on the sensing rights subscribed by the terminal.

[0536] In step 7023, the UDM sends a perception authorization response to the perception server, where the perception authorization response is used to indicate authorization or rejection of the first perception request.

[0537] If the perception authorization reply indicates that the first perception request is denied authorization, step 703 may be executed; if the perception authorization reply indicates that the first perception request is authorized, some of steps 704 to 713 may be executed.

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

[0539] Optionally, when the perception authorization reply indicates a refusal to authorize the first perception request, the perception authorization reply may also indicate a reason for the refusal.

[0540] For a more detailed description of step 702, please refer to the relevant content of step 502 of method 500, which will not be repeated here.

[0541] In step 703, the perception server sends a rejection message to the AS.

[0542] The specific process of the perception 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. Please refer to the relevant instructions in step 503 of method 500 and will not be repeated here.

[0543] In step 704, the perception server determines whether the terminal is allowed to be perceived.

[0544] The specific process of the perception server determining whether the terminal is allowed or not to be perceived is similar to the specific process of step 505 of method 500. Please refer to the relevant description in step 505 of method 500 above and will not be repeated here.

[0545] Optionally, the method further includes step 705: the perception server obtains perception notification feedback from the terminal.

[0546] The perception server can obtain perception notification feedback 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 705 specifically includes: the perception server sending the perception notification request; and the perception server obtaining perception notification feedback based on the response message to the perception notification request.

[0547] Unlike methods 500 and 600, the awareness server can interact with the awareness client installed in the terminal on the user plane without having to go through the AMF and RAN nodes. Therefore, the awareness server can send the awareness notification request to the awareness client and receive a response message to the awareness notification request from the awareness client.

[0548] The figure shows a possible implementation of step 705 from the perspective of device interaction. Exemplarily, step 705 includes the following steps 7051 to 7054:

[0549] Step 7051: The perception server sends a perception notification request to the perception client.

[0550] In step 7052, the perception client sends a response message of the perception notification request to the perception server, where the response message of the perception notification request indicates whether the terminal replies that it agrees to be perceived, whether the terminal replies that it disagrees to be perceived, or whether the terminal does not reply.

[0551] Step 7053: The perception server obtains perception notification feedback according to the response message of the perception notification request.

[0552] For example, after receiving the perception notification request from the perception server, the perception client can send the perception notification request to the operating system (OS) to request the OS to obtain and feedback the user's response. After obtaining the user's response, the OS can respond to the perception notification request, such as responding to agree or disagree to be perceived, or it can not respond if it does not obtain the user's response.

[0553] One possible scenario is that the perception client may or may not receive a response from the OS. The perception client can instruct the terminal to reply with consent to perception, or to reply with disapproval, or to indicate that the terminal has not replied, by sending a response message to the perception notification request to the perception server. The perception server can obtain perception notification feedback based on the response message to the perception notification request from the perception client, and then determine whether the terminal allows perception based on the perception rights contracted by the terminal and the perception notification feedback.

[0554] Another possible scenario is that the perception client can, upon receiving a reply from the OS side, instruct the terminal to reply that it agrees to be perceived, or instruct the terminal to reply that it disagrees to be perceived, by sending a response message to the perception notification request to the perception server. The perception client may also not obtain a reply from the OS side. In this case, the perception client does not send a response message to the perception notification request to the perception server. The perception server can determine that the terminal has not responded based on the expiration of a local timer. In other words, step 7052 is not necessarily executed, and the perception server can obtain perception notification feedback based on the response message to the perception notification request from the perception client. Specifically, it may include: the perception server can obtain perception notification feedback based on the information indicated by the response message to the perception notification request from the perception client, or based on whether a response message to the perception notification request from the perception client is received.

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

[0556] In step 706, the perception server obtains the target service requirements.

[0557] Optionally, step 706 includes: the perception server determines target business requirements.

[0558] In a possible design, the SF may pre-store a service requirement, which may be referred to as a default service requirement. The SF may directly determine the target service requirement if the terminal allows it to be sensed.

[0559] In another possible design, the perception request may carry a requested service requirement, and the SF may determine the requested service requirement as the target service requirement if the terminal allows perception. Alternatively, the SF may define a default service requirement as the requested service requirement without pre-configuring the default service requirement.

[0560] In another possible design, the target service requirement can be determined based on the time information of the first perception request and / or the location of the terminal. In other words, the perception service end can determine the target service requirement based on the time information of the first perception request and / or the location of the terminal.

[0561] A possible implementation method for the perception server to determine the target service requirement based on 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 based on the first mapping relationship and the time information of the first perception request. The first mapping relationship may include a correspondence between at least one service requirement and at least one time period.

[0562] Another possible implementation method for the perception server to determine the target service requirements based on the time information of the first perception request and / or the location of the terminal is that the perception server determines the target service requirements based on the location of the terminal and a second mapping relationship, where the second mapping relationship includes a correspondence between at least one service requirement and at least one area.

[0563] One possible implementation method is that the perception server determines the target service requirement based on the time information of the first perception request and / or the location of the terminal. Another possible implementation method is that the perception server determines the target service requirement based on the time information of the first perception request, the location of the terminal and a third mapping relationship, and the third mapping relationship includes a correspondence between at least one service requirement and at least one combination of area and time period.

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

[0565] Optionally, step 706 includes: the perception server obtains the target service requirement from the UDM.

[0566] The specific process of the perception server obtaining the target business requirement from the UDM is similar to the specific process of the SF obtaining the target business requirement from the UDM in step 508b of the above method 500. Please refer to the relevant description in step 805b and will not be repeated here.

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

[0568] In step 707, the perception server sends a service requirement confirmation request to the AS, where the service requirement confirmation request is used to request the adoption of the target service requirement.

[0569] In step 708, the AS sends a service requirement confirmation reply to the perception server, where the service requirement confirmation reply indicates whether or not to adopt the target service requirement.

[0570] The specific process of steps 707 to 708 is similar to steps 509 to 510 of method 500. Please refer to the relevant description of steps 509 to 510 of method 500 and will not be repeated here.

[0571] It is understandable that if the business requirement confirmation reply indicates that the target business requirement is agreed to be adopted, steps 709 to 712 may be executed; if the business requirement confirmation reply indicates that the target business requirement is not agreed to be adopted, step 713 may be executed.

[0572] In step 709, the perception server sends a second perception request to the SF, where the second perception request carries the target service requirements.

[0573] The perception server may send a second perception request to the SF if the AS agrees to adopt the target service requirement, and the second perception request carries the target service requirement.

[0574] The awareness server may process the first awareness request received in step 701 to obtain a second awareness requirement. For example, the awareness server may replace the terminal's external identifier in the first awareness request with the terminal's SUPI and include the target service requirement in the second awareness request. In other words, the second awareness request includes the terminal's SUPI and the target service requirement, as well as one or more of the following: an AS identifier or a requested service type.

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

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

[0577] For the specific content of the SF initiating the terminal perception process based on the target service requirements, please refer to the relevant description in step 511 of method 500, which will not be repeated here.

[0578] In step 711, the SF sends the perception result to the perception server.

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

[0580] In step 712, the perception server sends the perception result to the AS.

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

[0582] In step 713, the perception server sends a rejection message to the AS.

[0583] The perception server may send a rejection message to the AS via the user plane.

[0584] The specific process of steps 711 to 713 is similar to the specific process of steps 512 to 513 of method 500. Please refer to the relevant description of steps 512 to 513 of method 500 and will not be repeated here.

[0585] The above, combined with FIG7 , illustrates another possible process flow for the method provided herein. The steps shown in FIG7 are merely examples and do not necessarily require execution of all steps. For example, steps 703 and 704 may be performed alternatively, steps 709 to 712 and step 713 may be performed alternatively, and so on. The sequence numbers of the steps do not imply a specific order of execution; the order of execution of the steps should be determined by their functions and inherent logic.

[0586] It should be understood that method 700 has the same processing logic as method 500 , and therefore method 700 has similar technical effects as method 500 , which will not be described in detail.

[0587] FIG8 is another schematic flow chart of the perception method provided in an embodiment of the present application. The method 800 shown in FIG8 is similar to the processing flow of the method 600 shown in FIG6 and is applicable to the same network architecture as the method 700 shown in FIG7. For the same or similar steps as those in the method 600 or 700, and the description of the same terms, please refer to the relevant description of the method 600 or 700 above. The method 700 is similar to the processing flow of the method 500 shown in FIG5. For the same or similar steps as those in the method 500, and the description of the same terms, please refer to the relevant description of the method 500 above, which will not be repeated here.

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

[0589] In step 801, the AS sends a first perception request to the perception server, where the first perception request is used to request perception of the terminal.

[0590] In step 802, the awareness server obtains authorization for the awareness request from the UDM.

[0591] The perception server may obtain authorization from the UDM for the first perception request by sending a perception authorization request to the UDM. The UDM may indicate authorization or rejection of the first perception request through a perception authorization reply. If the perception authorization reply indicates rejection of authorization, step 803 may be executed. If the perception authorization reply indicates authorization, some of steps 804 to 813 may be executed.

[0592] In step 803, the perception server sends a rejection message to the AS.

[0593] The specific process of steps 801 to 803 is the same as that of steps 701 to 703 in method 700, and the specific process of steps 701 to 703 in method 700 is similar to that of steps 501 to 503 in method 500. Therefore, you can refer to steps 501 to 503 of method 500 and the relevant instructions in steps 701 to 703 in method 700, and no further details will be given.

[0594] In step 804, the perception server obtains the perception notification feedback from the terminal.

[0595] The perception server can obtain the terminal's perception notification feedback 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 804 specifically includes: the perception server sending the perception notification request; and the perception server obtaining the terminal's perception notification feedback based on the response message to the perception notification request.

[0596] Unlike methods 500 and 600, the awareness server can interact with the awareness client installed in the terminal on the user plane without having to go through the AMF and RAN nodes. Therefore, the awareness server can send the awareness notification request to the awareness client and receive a response message to the awareness notification request from the awareness client.

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

[0598] Step 8041: The perception server sends a perception notification request to the perception client.

[0599] In step 8042, the perception client sends a response message to the perception notification request to the perception server, where the response message to the perception notification request carries perception notification feedback.

[0600] Step 8043: The perception server obtains perception notification feedback according to the response message of the perception notification request.

[0601] For a more detailed description of step 804 , please refer to the relevant content of step 704 in method 700 , which will not be repeated here.

[0602] Different from method 700 , the perception server can obtain the target service requirements without determining whether the terminal is allowed to be perceived. Therefore, the perception server does not need to first determine whether the terminal is allowed to be perceived, but directly executes step 805 .

[0603] In step 805, the perception server obtains the target service requirements.

[0604] In one implementation, the perception server may determine the target service requirements based on the perception rights subscribed by the terminal and / or the perception notification feedback from the terminal. In another implementation, the perception server may send a service requirement request to the data management function network element, where the service requirement request carries the perception notification feedback from the terminal. The data management function network element may determine the target service requirements based on the perception rights subscribed by the terminal and / or the perception notification feedback from the terminal.

[0605] Furthermore, the target service requirement can also be determined in combination with the terminal's location and / or time information. If the target service requirement is obtained by the perception service end by sending a service requirement request to the data management function network element, the service requirement request accordingly carries the location information and / or time information.

[0606] In a specific implementation, the perception server or data management function network element can determine the target service requirements based on the mapping relationship and one or more of the following: the perception authority subscribed by the terminal, perception notification feedback, time period or area.

[0607] The specific process of the perception server obtaining the target service requirement is similar to the specific process of step 607 of method 600. Please refer to the relevant description of step 607 of method 600 above and will not be repeated here. In step 806, the perception server sends a service requirement confirmation request to the AS, which is used to request the adoption of the target service requirement.

[0608] In step 807, the AS sends a service requirement confirmation reply to the perception server, where the service requirement confirmation reply indicates whether or not to adopt the target service requirement.

[0609] In step 808, the perception server sends a second perception request to the SF, where the second perception request carries the target service requirements.

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

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

[0612] For details about the SF initiating the terminal perception process based on the target service requirements, please refer to the relevant description in step 511 of method 500, which will not be repeated here.

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

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

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

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

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

[0618] The perception server may send a rejection message to the AS via the user plane.

[0619] The specific process of steps 806 to 812 is the same as the specific process of steps 707 to 713 of method 700. Please refer to the relevant description of steps 707 to 713 of method 700 and will not be repeated here.

[0620] The above description, combined with FIG8 , illustrates another possible process flow for the method provided herein. The steps shown in FIG8 are merely examples and do not necessarily require execution of all steps. For example, step 803 and steps 804 to 812 may be performed alternatively, steps 808 to 811 and step 812 may be performed alternatively, and so on. The sequence numbers of the steps do not imply a specific order of execution; the order of execution of the steps should be determined by their functions and inherent logic.

[0621] It should be understood that method 800 has the same processing logic as method 600 , and therefore method 800 has similar technical effects as method 600 , which will not be described in detail.

[0622] The above text, in conjunction with Figures 5 to 8, exemplarily illustrates several possible processes of the perception method provided by the present application. It is not difficult to see that in the embodiments shown in Figures 5 to 8, the second communication device (such as the SF in Figures 5 and 6, or the perception service end in Figures 7 and 8) can obtain the target service requirements after receiving the perception request, and the target service requirements are related to the perception authority of the terminal being perceived. For ease of understanding, the perception method provided by the present application will be briefly described below in conjunction with Figure 9.

[0623] FIG9 is another schematic flow chart of the perception method provided by an embodiment of the present application. FIG9 illustrates the method from the perspective of device interaction. As shown in FIG9 , the method 900 includes steps 901 to 909.

[0624] The following describes each step in method 900 in detail.

[0625] In step 901, a second communication device receives a sensing request.

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

[0627] The perception request may also be sent directly from the first communication device to the second communication device, for example, by an AS to the perception server.

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

[0629] Step 901 may correspond to steps 501 to 503 in method 500, steps 601 to 603 in method 600, step 701 in method 700, or step 801 in method 800. Therefore, the specific process of step 901 can refer to the relevant descriptions of the corresponding steps in method 500, method 600, method 700, or method 800, and will not be repeated here.

[0630] In step 902, the second communication device obtains a target service requirement, where the target service requirement is related to the perception authority of the terminal.

[0631] The target service requirement is related to the perception authority of the terminal, including: the target service requirement is obtained when it is determined that the terminal is allowed to be perceived, and / or the target service requirement is determined according to the perception authority of the terminal.

[0632] Therefore, this application provides at least two processing logics to obtain target service requirements.

[0633] One processing logic is to obtain the target service requirements when determining that the terminal allows perception. Optionally, the method further includes step 903: the second communication device determines that the terminal allows perception. The second communication device can determine that the terminal allows perception based on the perception rights subscribed by the terminal and / or the perception notification feedback from the terminal.

[0634] If it is determined that the terminal allows being sensed, the second communication device may determine the target service requirement on its own, as shown in 902a in the figure, or may request 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 based on the location and / or time information of the terminal.

[0635] Step 903 may correspond to step 505 in the above method 500 or step 704 in the above method 700. Therefore, the specific process of step 903 can refer to the relevant description of the corresponding steps in the above methods 500 or 700, and will not be repeated here.

[0636] In this processing logic, step 902 may correspond to step 508 in method 500 or step 706 in method 700. Therefore, the specific process of step 902 can refer to the relevant description of the corresponding steps in method 500 or 700 above, and will not be repeated here.

[0637] Another processing logic is to obtain the target business requirements without determining whether the terminal is allowed to be perceived, and the target business requirements can be determined based on the perception authority of the terminal, specifically based on the perception authority signed by the terminal and the perception notification feedback of the terminal.

[0638] After receiving the terminal's perception notification feedback, the second communication device can independently determine the target service requirements, as shown in 902a in the figure, or the data management function network element can send a service requirement request, which carries the perception notification feedback and is used to request the target service requirements and send it to the data management function network element, as shown in 902b in the figure. The target service requirements can be determined based on the perception rights subscribed by the terminal and / or the perception notification feedback. Furthermore, the target service requirements can also be determined based on the terminal's location and / or time information.

[0639] In this processing logic, step 902 may correspond to step 607 in method 600 or step 805 in method 800. Therefore, the specific process of step 903 can refer to the relevant description of the corresponding steps in method 600 or 800 above, and will not be repeated here.

[0640] It should be understood that the two processing logics exemplified above are only two possible implementation methods and should not constitute any limitation to this application. It is not difficult to see that these two processing logics are essentially related to the perception authority of the terminal, and the perception authority of the terminal can include the perception authority of the terminal contract and / or the perception notification feedback of the terminal. Therefore, it can also be considered that the target service requirements are determined based on the perception authority of the terminal contract and / or the perception notification feedback of the terminal. Therefore, in the specific implementation, these two processing logics can be used alone or in combination. For example, after receiving the 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 based on the perception authority of the terminal contract and / or the perception notification feedback of the terminal, and then determine the target service requirements. This application does not limit this.

[0641] Furthermore, in the two processing logics exemplified above, the second communication device may 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.

[0642] Optionally, the method further includes step 904, obtaining perception notification feedback from the terminal, where the perception notification feedback indicates whether the terminal responds that it agrees to be perceived, responds that it disagrees to be perceived, or does not respond. Exemplarily, the second communication device may obtain the perception notification feedback from the terminal by sending a perception notification request.

[0643] Step 904 may correspond to step 506 in method 500, step 606 in method 600, step 705 in method 700 or step 804 in method 800. Therefore, the specific process of step 904 can refer to the relevant description of the corresponding steps in the previous method 500, method 600, method 700 or method 800, and will not be repeated here.

[0644] Optionally, the method further includes step 905, where the second communication device sends a service requirement confirmation request to the first communication device, where the service requirement confirmation request is used to request adoption of the target service requirement. Accordingly, the first communication device receives the service requirement confirmation request from the second communication device.

[0645] 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 perception request.

[0646] Optionally, the method further includes step 906, where the first communication device sends a service requirement confirmation reply to the second communication device, where the service requirement confirmation reply indicates whether or not to adopt the target service requirement. Accordingly, the second communication device receives the service requirement confirmation reply from the first communication device.

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

[0648] If the service requirement confirmation reply indicates that the target service requirement is agreed to be adopted, the second communication device may initiate a perception process for the terminal based on the target service requirement.

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

[0650] After obtaining the perception result, the second communication device may send the perception result to the first communication device.

[0651] Optionally, the method further includes step 909, where the second communication device sends a rejection message to the first communication device, where 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.

[0652] If the service requirement confirmation reply indicates that the target service requirement is not adopted, the second communications device may reject the sensing request.

[0653] 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 refer to the relevant descriptions of the corresponding steps in method 500, method 600, method 700, or method 800 above, and will not be repeated here.

[0654] Optionally, the method further includes: the second communication device obtaining, from the data management function network element, the perception authority of the terminal contract and / or the mapping relationship for determining the target service requirement. Accordingly, the data management function network element sends the perception authority of the terminal contract and / or the mapping relationship for determining the target service requirement to the second communication device.

[0655] In the solution provided by the present application, the target business requirements for determining the KPI for perceiving the terminal are related to the perception authority of the terminal, so that the perception process initiated for the terminal is adapted to the perception authority of the terminal, rather than blindly determining the KPI for perceiving the terminal directly based on the business requirements requested by the AF network element or AS. In other words, the present application can obtain target business requirements based on the terminal granularity. Specifically, the target business requirements of different terminals can be determined according to their corresponding perception authority. Therefore, taking into account the security needs of different terminals, different target business requirements are flexibly obtained according to the perception authority of different terminals, and then the perception process is initiated for different terminals based on different KPIs, rather than blindly using the same KPI to perceive all terminals requested for perception based on the business requirements requested by the AF network element or AS.

[0656] The above describes the sensing method provided by the embodiment of the present application in detail with reference to the accompanying drawings. The following describes the device provided by the embodiment of the present application in detail with reference to the accompanying drawings.

[0657] Figures 10 and 11 are schematic block diagrams of possible communication devices provided in embodiments of the present 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, thereby also achieving the beneficial effects of the above method embodiments.

[0658] A communication device provided in this application is shown in FIG10 , where the communication device 1000 includes a communication unit 1010 and a processing unit 1020 .

[0659] One possible design is that the communication device 1000 is used to implement the functions of the second communication device in any of the method embodiments shown in Figures 5 to 9 above. 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 the perception server in the method embodiment shown in Figure 7 or Figure 8, or a component configured in the SF or perception server (such as a chip, chip system, processor, etc.), or a logic module or software that can implement some or all of the functions of the SF or perception server.

[0660] Exemplarily, the communication unit 1010 is used to receive a perception request, which is used to request perception of the terminal; the processing unit 1020 is used to obtain target business requirements, which are used to determine the KPI for perceiving the terminal, and the target business requirements are related to the perception authority of the terminal, and the perception authority is used to determine whether the terminal is allowed or not to be perceived.

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

[0662] Optionally, the processing unit 1020 is specifically used to determine that the terminal allows perception based on the perception authority and / or perception notification feedback signed by the terminal, and the perception notification feedback indicates that the terminal replies to agree to be perceived or the terminal has not replied.

[0663] Optionally, the communication unit 1010 is further configured to obtain the perception authority of the terminal contract from the data management function network element.

[0664] Optionally, the communication unit 1010 is also used to send a service requirement request to the data management function network element, where 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, where the target service requirement is determined based on the service requirement request.

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

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

[0667] Optionally, the communication unit 1010 is further used to send a perception notification request, which 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 based on the response message of the perception notification request.

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

[0669] Optionally, the perception request indicates a requested service type, and the service requirement request message also indicates the service type.

[0670] Optionally, the processing unit 1020 is specifically configured to determine the target service requirement based on the location of the terminal and / or the time information of the perception request.

[0671] Optionally, the processing unit 1020 is specifically used to determine the target business requirements based on the perception authority, perception notification feedback and mapping relationship signed by the terminal, the perception notification feedback indicates that the terminal responds to the perception notification request and agrees to be perceived or the terminal does not respond to the perception notification request, the perception notification request is used to request the terminal to reply whether it agrees to be perceived, and the mapping relationship includes a correspondence between at least one combination of perception authority and perception notification feedback and at least one business requirement.

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

[0673] Optionally, the perception request comes from a first communication device, and the perception request also carries the requested business requirements. The communication unit 1010 is also used to: send a business requirement confirmation request to the first communication device, and the business requirement confirmation request is used to request the adoption of the target business requirements, and the target business requirements are different from the requested business requirements; receive a business requirement confirmation reply from the first communication device, and the business requirement confirmation reply indicates whether to agree or disagree to adopt the target business requirements; the processing unit 1020 is also used to, when the business requirement confirmation reply indicates agreement to adopt the target business requirements, initiate a perception process for the terminal based on the target business requirements; the communication unit 1010 is also used to, when the business requirement confirmation reply indicates disagreement to adopt the target business requirements, send a rejection message to the first communication device, and the rejection message is used to reject the perception request.

[0674] 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 perceived, wherein the rejection message is used to reject the perception request.

[0675] Optionally, the rejection message also indicates the reason for rejecting the perception request.

[0676] A more detailed description of the communication unit 1010 and the processing unit 1020 can be directly obtained by referring to the relevant descriptions in the method embodiments shown in Figures 5 to 9, and will not be repeated here.

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

[0678] Exemplarily, the communication unit 1010 is used to receive a service requirement request from a second communication device, wherein the service requirement request is used to request acquisition of a target service requirement, and the target service requirement is used to determine the KPI for perceiving the terminal; the processing unit 1020 is used to determine the target service requirement, and the target service requirement is related to the perception authority of the terminal; the communication unit 1010 is also used to send the target service requirement to the second communication device.

[0679] Optionally, the service requirement request carries perception notification feedback, the perception notification feedback indicates that the terminal responds to the perception notification request and agrees to be perceived or that the terminal has not responded to the perception notification request, and the perception notification request is used to request the terminal to respond whether it agrees to be perceived. The processing unit 1020 is specifically used to determine the target service requirement based on the perception authority of the terminal, the perception notification feedback, and a mapping relationship, wherein the mapping relationship includes a correspondence between at least one combination of perception authority and perception notification feedback and at least one service requirement.

[0680] Optionally, the service requirement request indicates that the terminal allows perception and one or more of the following: the location of the terminal, time information of the perception request, or time information of the service requirement request, and the perception request is used to request perception of the terminal. The processing unit 1020 is specifically configured to determine the target service requirement based on one or more of the following: the location of the terminal, the time information of the perception request, or the time information of the service requirement request.

[0681] Optionally, the communication unit 1020 is further configured to receive a sensing authority of a terminal contract sent from the second communication device.

[0682] Exemplarily, the communication unit 1020 is used to: receive a perception authorization request from a third communication device, the perception authorization request is used to request authorization of a perception request, and the perception request is used to request perception of the terminal; and send a perception authorization reply to the third communication device based on the perception authority of the terminal, the perception authorization reply indicating authorization of the perception request or refusal to authorize the perception request.

[0683] Optionally, the perception authorization reply indicates authorization of the perception request, and the perception authorization reply carries the perception authority signed by the terminal and / or a mapping relationship for determining target business requirements, and the target business requirements are used to determine the KPI for perceiving the terminal.

[0684] A more detailed description of the communication unit 1010 and the processing unit 1020 can be directly obtained by referring to the relevant descriptions in the method embodiments shown in Figures 5 to 9, and will not be repeated here.

[0685] It should be noted that the communication unit may also be referred to as a transceiver unit, transceiver module, transceiver, transceiver, or transceiver device. The processing unit may also be referred to as a processor, processing board, processing module, or processing device. Optionally, the communication unit is configured to perform the sending and receiving operations of the second communication device or the data management function module in the above method. The device in the communication unit that implements the receiving function may be considered a receiving unit, and the device in the communication unit that implements the sending function may be considered a sending unit. That is, the communication unit includes a receiving unit and a sending unit.

[0686] It should also be noted that, in one possible design, the aforementioned communication unit and / or processing unit may be implemented through a virtual module. For example, the processing unit may be implemented through a software function unit or a virtual device, and the communication unit may be implemented through a software function or a virtual device. In another possible design, the processing unit or the communication unit may also be implemented through a physical device. For example, if the device is implemented using a chip / chip circuit, the communication unit may be an input / output circuit and / or a communication interface that performs input operations (corresponding to the aforementioned receiving operations) and output operations (corresponding to the aforementioned sending operations); the processing unit is an integrated processor or microprocessor or integrated circuit.

[0687] The division of units in the embodiments of the present application is schematic and is merely a logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various examples of the embodiments of the present application may be integrated into a single processor, or may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0688] Another communication device provided in the present application is shown in FIG11 , where the communication device 1100 includes at least one processor 1110. The at least one processor 1110 may be configured to execute computer programs or instructions in a memory to implement the steps performed by the second communication device (e.g., SF or perception server), the steps performed by the data management function network element (e.g., UDM), or the steps performed by the first communication device (e.g., AS or AF) in any of the method embodiments shown in FIG5 to FIG9 .

[0689] Optionally, the communication device 1100 may further include at least one memory 1120 for storing instructions executed by the processor 1110 or storing input data required by the processor 1110 to execute instructions or storing data generated after the processor 1110 executes instructions. The at least one processor 1110 and the at least one memory 1120 may be provided separately. For example, each memory may be connected to one or more processors so that the connected processors can read information from the memory and store and / or write information in the memory. Alternatively, the at least one processor 1110 and the at least one memory 1120 may be integrated together, for example, one or more memories may be integrated into a processor.

[0690] 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 is understood that the interface circuit 1130 can be a transceiver, input / output circuit, bus, module, pin, or other type of communication interface, wherein the input circuit of the input / output circuit can be used for receiving, and the output interface can be used for sending.

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

[0692] When the communication device 1100 is used to implement the methods shown in Figures 5 to 9, the processor 1111 is used to perform the functions of the processing unit described above, and the interface circuit 1120 is used to perform the functions of the receiving unit and / or the transmitting unit described above. Whether the interface circuit 1120 is used for sending or receiving can be determined by whether the communication device 1100 is used to perform a sending action or a receiving action in the solution implemented.

[0693] It is understandable that when the communication device 1100 is a communication device (e.g., SF, perception server, data management function network element, AF, or AS), the interface circuit 1120 may be a transceiver, specifically including a transmitter and a receiver, the transmitter being used to send signals, and the receiver being used to receive signals. When the communication device 1100 is a chip applied to a communication device, the interface circuit 1120 may be an input / output circuit, a bus, a module, a pin, or other type of communication interface, wherein the input circuit in the input / output circuit may be used for receiving, and the output interface may be used for sending.

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

[0695] 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 exchange between devices, units or modules. In the embodiments of the present application, the specific connection medium between the at least one processor 1110, the at least one memory 1120, the interface circuit 1130 and the power supply circuit 1140 is not limited. In Figure 11, the embodiment of the present application shows that the processor 1110, the memory 1120, the interface circuit 1130 and the power supply circuit 1140 are connected via a bus 1150. The bus 1150 is represented by a bold line in Figure 11, and the connection method between other components is only for schematic illustration and is not limited. 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 ease of representation, only one bold line is used in Figure 11, but it does not mean that there is only one bus or one type of bus.

[0696] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), 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.

[0697] 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 read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (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 and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM bus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

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

[0699] Exemplarily, the communication system includes SF and UDM. Optionally, the communication system also includes a perception server. Optionally, the communication system also includes NEF.

[0700] The present application also provides a computer program product, which includes: a computer program (also referred to as code, or instructions), which, when run, enables the computer to execute the method executed by the second communication device, the data management function network element, or the first communication device in the embodiment shown in 9, or enables the computer to execute the method executed by the data management function network element in any of the embodiments shown in Figures 5 to 8, or enables the computer to execute the method executed by the SF in the embodiment shown in Figure 5 or 6, or enables the computer to execute the method executed by the perception server in Figure 7 or 8.

[0701] The present application also provides a computer-readable storage medium storing a computer program (also referred to as code or instruction). When the computer program is executed, the computer executes the method executed by the second communication device, the data management function network element, or the first communication device in the embodiment shown in Figure 9, or the computer executes the method executed by the data management function network element in any of the embodiments shown in Figures 5 to 8, or the computer executes the method executed by the SF in the embodiment shown in Figure 5 or Figure 6, or the computer executes the method executed by the perception server in Figure 7 or Figure 8.

[0702] The terms "unit," "module," and the like used in this specification may be used to refer to a computer-related entity, hardware, firmware, a combination of hardware and software, software, or software in execution.

[0703] Those skilled in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed devices, equipment, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not performed. In addition, the coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, and can be electrical, mechanical, or other forms.

[0704] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of the solution of this embodiment according to actual needs.

[0705] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0706] 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 (program) are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0707] 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, or the part that contributes to the prior art, or the part of the 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 for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0708] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection 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, wherein 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, wherein 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, wherein The method further includes: Sending a sensing notification request for requesting the terminal to reply to agree or disagree 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, characterized in that, The service requirement request carries the sensing notification feedback, where the sensing notification feedback indicates that the terminal replies to agree to be sensed to the sensing notification request or the terminal does not reply, and the sensing notification request is used to request the terminal to reply to agree or disagree 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 the mapping relationship, where the sensing notification feedback indicates that the terminal replies to agree to be sensed to the sensing notification request 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, 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 used to request 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 to agree or disagree to adopt the target service requirement; and When the business requirement confirmation reply indicates agreement to adopt the target business requirement, initiate a sensing process for the terminal based on the target business requirement; or When 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: When it is determined 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 the acquisition of 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 sensing of 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 sensing of the 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 rejection of authorization for the sensing request.

21. The method according to claim 20, characterized in that, 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 sensing of the 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 refusal to authorize the sensing request.

23. The method according to claim 22, wherein The sensing authorization reply indicates authorization for the sensing request, and the sensing authorization reply carries the sensing permissions 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 key performance indicators (KPIs) 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 need to notify the terminal but without the terminal's feedback, 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.

25. A perception method, characterized in that, Include: Receive a service requirement confirmation request from a second communication device, where the service requirement confirmation request is used to request the adoption of target service requirements that are different from the requested service requirements. Send a service requirement confirmation reply to the second communication device, where the service requirement confirmation reply indicates consent or disagreement to adopt the target service requirements.

26. The method according to claim 25, wherein The method further includes: Receive a rejection message from the second communication device, where the rejection message is used to reject a sensing request for requesting to sense a terminal.

27. The method according to claim 26, wherein The rejection message further indicates the reason for rejecting the sensing request.

28. A perception method, characterized in that, Include: A second communication device receives a sensing request for requesting to sense a terminal. The second communication device obtains target service requirements from a data management function network element, where the target service requirements are used to determine the KPIs for sensing the terminal.

29. The method according to claim 28, wherein The second communication device obtaining target service requirements from a data management function network element includes: When the second communication device determines that the terminal is allowed to be sensed, it sends a service requirement request to the data management function network element, where the service requirement request indicates that the terminal is allowed to be sensed. The data management function network element determines the target service requirements. The data management function network element sends the target service requirements to the second communication device.

30. The method according to claim 29, wherein The target service requirements carry 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.

31. The method according to claim 29 or 30, characterized in that, The second communication device determining that the terminal is allowed to be sensed includes: The second communication device determines that the terminal is allowed to be sensed according to the sensing permissions subscribed by the terminal and / or the sensing notification feedback of the terminal, where the sensing notification feedback indicates that the terminal replies consent to be sensed or the terminal does not reply.

32. The method according to claim 31, wherein The method further includes: 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 consents 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 consent to be sensed or the terminal does not reply.

33. The method according to claim 31 or 32, characterized in that, The method further includes: The second communication device obtains the sensing permissions subscribed by the terminal from the data management function network element.

34. The method according to any one of claims 29 to 33, characterized in that, The data management function network element determines the target service requirements, including: The data management function network element determines the target service requirements according to the mapping relationship, where 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 permissions subscribed by the terminal, the sensing notification feedback of the terminal, the location of the terminal, the time information of the sensing request, or the time information of the service requirement request.

35. A communication system, characterized in that, including one or more of a first communication device, a second communication device, or a data management function network element; Wherein, the second communication device is used to execute the sensing method according to any one of claims 1 to 15, the data management network element is used to execute the sensing method according to any one of claims 16 to 24, and the first communication device is used to execute the sensing method according to any one of claims 25 to 27.

36. A communication device, characterized in that, including one or more functional units for implementing the method according to any one of claims 1 to 27.

37. A communication device, characterized in that, including a processor, where the processor is used to execute program code to enable the communication device to implement the method according to any one of claims 1 to 27.

38. 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 27 is executed.

39. A computer program product, characterized in that, including a computer program, when the computer program is run, the method according to any one of claims 1 to 27 is executed.

Images