[go: up one dir, main page]

WO2025149036A1 - 感知方法、通信装置和系统 - Google Patents

感知方法、通信装置和系统

Info

Publication number
WO2025149036A1
WO2025149036A1 PCT/CN2025/071749 CN2025071749W WO2025149036A1 WO 2025149036 A1 WO2025149036 A1 WO 2025149036A1 CN 2025071749 W CN2025071749 W CN 2025071749W WO 2025149036 A1 WO2025149036 A1 WO 2025149036A1
Authority
WO
WIPO (PCT)
Prior art keywords
perception
terminal
request
service requirement
target service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/071749
Other languages
English (en)
French (fr)
Inventor
雷骜
吴义壮
朱方园
应江威
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2025149036A1 publication Critical patent/WO2025149036A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/183—Processing at user equipment or user record carrier
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data

Definitions

  • the present application relates to the field of communications, and in particular to a sensing method, a communication device and a system.
  • some base stations or terminals in the radio access network can be used as sensing nodes because they have the sensing ability brought by electromagnetic waves.
  • the realization of perception is similar to the principle of radar. That is, the transmitter transmits electromagnetic waves, which are reflected by the object to be sensed and then acquired by the receiver. The receiver can further process the acquired reflection signal (which can be called sensing raw data) to obtain sensing data, which can be used to obtain sensing results.
  • the above transmitters and receivers can be called sensing nodes.
  • 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 directly send a perception request to the network element responsible for the perception function in the communication network.
  • the network element responsible for the perception function in the communication network can initiate the perception process for the specific terminal.
  • the present application provides a perception method, a communication device and a system, so as to flexibly respond to perception request messages according to the security requirements of terminal devices to meet the security requirements of different terminal devices.
  • a sensing method is provided, which can be applied to a second communication device, which can be, for example, a sensing function (SF) network element or a sensing server, or a component configured in the SF network element or the sensing server, such as a processor, a chip, a chip system, etc., or a logic module or software capable of implementing all or part of the functions of the second communication device.
  • SF sensing function
  • the method includes: receiving a perception request, the perception request is used to request perception of a terminal; obtaining a target business requirement, the target business requirement is used to determine a key performance indicator (KPI) for perceiving the terminal, 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.
  • KPI key performance indicator
  • 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.
  • a first communication device such as an AF network element or an AS
  • the terminal may be any terminal requested for perception.
  • 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 according to the business requirements requested by the AF network element or AS.
  • 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.
  • the perception authority of the terminal includes: the perception authority subscribed by the terminal, the perception notification feedback of the terminal, or the 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.
  • 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.
  • the sensing authority contracted by the terminal is the sensing authority contracted by the terminal and the network operator, which can also be called the configured sensing authority, the default sensing authority, or the sensing authority stored on the network side.
  • the terminal can clarify whether it allows itself to be sensed by signing a contract with the operator.
  • the sensing authority signed 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.
  • the perception authority signed by the terminal can indicate whether the terminal is allowed or not allowed to be perceived.
  • the terminal's perception notification feedback is used to indicate the terminal's response to the received perception notification request, and 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 does not allow perception, so it can also be called the perception authority of the terminal feedback.
  • the second communication device that receives the perception request can send a perception notification request to the terminal, and the perception notification request can be used to request the terminal to reply whether it agrees to be perceived.
  • the terminal may not be possible to determine whether the terminal is allowed to be sensed simply based on the sensing authority signed by the terminal or the sensing notification feedback of the terminal, and a combination of the two is required to determine.
  • the sensing authority signed by the terminal is: the terminal needs to be notified, and sensing is allowed when the terminal replies with consent or does not reply, or the terminal needs to be notified, and sensing is allowed only when the terminal replies with consent.
  • the terminal needs to be notified, and perception is allowed when the terminal replies with consent or does not reply specifically means: the terminal needs to be notified, and perception is allowed when the terminal replies with consent or does not reply, and perception is not allowed when the terminal replies with disagreement;
  • the terminal needs to be notified, and perception is allowed only when the terminal replies with consent specifically means: the terminal needs to be notified, and perception is allowed when the terminal replies with consent, and perception is not allowed when the terminal replies with disagreement or does not reply.
  • Whether the terminal is allowed to be perceived can be determined based on whether the terminal responds to the received perception notification request or the content of the response.
  • the second communication device that receives the perception request can send a perception notification request to the terminal according to the perception authority signed by the terminal, and the perception notification request can be used to request the terminal to reply whether it agrees to be perceived.
  • the terminal can reply to the perception notification request with consent or disagreement, that is, the perception notification feedback of the terminal indicates that the terminal replies to agree to be perceived, and accordingly, the perception authority of the terminal indicates that it is allowed to be perceived, or the perception notification feedback of the terminal indicates that the terminal replies with disagreement to be perceived, and accordingly, the perception authority of the terminal indicates that it is not allowed to be perceived.
  • the terminal may also not reply to the perception notification request, that is, the perception notification feedback of the terminal indicates that the terminal has not replied, and at this time, it can be determined in combination with the perception authority signed by the terminal: if the perception authority signed by the terminal is that the terminal needs to be notified, and the perception is allowed when the terminal replies with consent or does not reply, then the perception authority of the terminal indicates that the terminal allows perception; if the perception authority signed by the terminal is that the terminal needs to be notified, and the perception is allowed only when the terminal replies with consent, then the perception authority of the terminal indicates that the terminal does not allow perception.
  • whether the terminal allows or does not allow being perceived is determined according to the perception authority subscribed by the terminal and/or the perception notification feedback of the terminal.
  • 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 a terminal reply, requiring notification of the terminal and allowing perception when the terminal replies with agreement or does not reply, or requiring notification of the terminal and allowing perception only when the terminal replies with agreement.
  • 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.
  • the perception authority of the terminal contract can be any one of the items listed above, or it can be other authorities, and this application includes but is not limited to this.
  • 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.
  • the sensing authority of the terminal contract may be different due to different locations and/or times. For example, the sensing authority of the terminal contract is different in area 1 and area 2, or the sensing authority of the terminal contract is different in time period 1 and time period 2, etc.
  • the security requirements of the terminal can be further met, so that the second communication device can respond to the sensing request more flexibly according to the sensing permissions of the terminal.
  • 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.
  • the target service requirement is obtained when it is determined that the terminal is allowed to be sensed, that is, when it is determined that the terminal is allowed to be sensed, the target service requirement is obtained; when it is determined that the terminal is not allowed to be sensed, the target service requirement is not obtained. Whether the terminal is allowed to be sensed or not is determined by the terminal's perception authority, or the terminal's perception authority, so the target service requirement is related to the terminal's perception authority.
  • the acquiring the target service requirement includes: acquiring the target service requirement when it is determined that the terminal is allowed to be sensed.
  • the determination that the terminal is allowed to be sensed means that it is determined by the sensing authority of the terminal that the terminal is allowed to be sensed, or in other words, the sensing authority of the terminal indicates that the terminal is allowed to be sensed.
  • determining that the terminal is allowed to be perceived includes: determining that 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.
  • whether the terminal is allowed or not allowed to be sensed can be determined based on the sensed authority subscribed to and/or the sensed notification feedback of the terminal.
  • 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.
  • the perception notification feedback of the terminal is obtained by sending a perception notification request to the terminal.
  • the response message of the perception notification request may be a response message to the perception notification request, which may be used to indicate the perception notification feedback.
  • a possible design is that the perception notification feedback is carried in the response message of the perception notification request.
  • the perception authority of the terminal contract may be obtained from the data management function network element, or may be pre-configured in the second communication device, and this application does not limit this. 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.
  • the target service requirements can be determined by a data management function network element (such as a unified data management (UDM) network element) and then sent to the second communication device; it can also be determined by the second communication device.
  • a data management function network element such as a unified data management (UDM) network element
  • the service requirement request may be sent to the data management function network element when the second communication device determines that the terminal is allowed to be perceived.
  • the sending of the service requirement request may be triggered by the condition that the terminal is allowed to be perceived.
  • the data management function network element may determine the target service requirement and send it to the second communication device.
  • the sending of the service requirement request may be used to implicitly indicate that the terminal is allowed to be perceived.
  • the data management function network element receives the service requirement request, it may assume that the terminal is allowed to be perceived.
  • the service requirement request further includes location information of the terminal and/or time information of the perception request.
  • the location information of the terminal is used to indicate the location of the terminal.
  • the location information may be carried in the service requirement request, for example.
  • 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 requested perception indicated by the perception request, or the time when the data management function network element receives the service request request.
  • the time information can be carried in the service request request, or can be determined by the data management function network element according to the time when the service request request is received, which is not limited in this application.
  • the target service requirement can be determined based on one or more of the information element (IE) and/or time information carried in the service requirement request.
  • the information element includes one or more of the following: the perception authority signed by the terminal, the indication that the terminal allows perception, the perception notification feedback, the location information, the time of initiating the perception request or the time of receiving the perception request.
  • the target service requirement can be determined based on one or more of the terminal's perception authority, perception notification feedback, the terminal's location, or time information.
  • the target service requirement can be determined based on a mapping relationship, which can include a corresponding relationship 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.
  • mapping relationships corresponding to the same terminal and different service types may be the same or different.
  • mapping relationship corresponds to the terminal and the requested service type.
  • both the security requirements of different terminals and different service requirements are taken into account, so that the perception request can be responded to more flexibly.
  • the perception request comes from a first communication device, and the perception request also carries a requested service requirement.
  • the method also includes: sending a service requirement confirmation request to the first communication device, the service requirement confirmation request is used to request the adoption of a target service requirement, which is different from the requested service requirement; receiving a service requirement confirmation reply from the first communication device, the service requirement confirmation reply indicating agreement or disagreement to adopt the target service requirement; initiating a perception process for the terminal based on the target service requirement when the service requirement confirmation reply indicates agreement to adopt the target service requirement; or sending a rejection message to the first communication device when the service requirement confirmation reply indicates disagreement to adopt the target service requirement.
  • the second communication device may further confirm with the first communication device whether to agree to adopt the target service requirement.
  • 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 lower than the requested service requirement.
  • 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.
  • 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.
  • 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.
  • the terminal is not allowed to be sensed. This has been explained in detail above in conjunction with the terminal's perception authority, so it will not be repeated here.
  • 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 that trigger the second communication device to send the rejection message are different, and either one can be sent.
  • the rejection message carries the reason for rejecting the perception request.
  • 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.
  • a perception method is provided, which can be applied to a data management function network element (such as a UDM), and the execution subject of the method can be, for example, a data management function network element, or a component configured in the data management function network element, such as a processor, a chip, a chip system, etc., or a logic module or software that can implement all or part of the functions of the communication device.
  • a data management function network element such as a UDM
  • the execution subject of the method can be, for example, a data management function network element, or a component configured in the data management function network element, such as a processor, a chip, a chip system, etc., or a logic module or software that can implement all or part of the functions of the communication device.
  • the method includes: receiving a service requirement request from a second communication device, the service requirement request is used to request to obtain a target service requirement, the target service requirement is used to determine a KPI for perceiving a terminal; determining the target service requirement, the target service requirement is related to the perception authority of the terminal, the perception authority of the terminal is 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.
  • the second communication device may be, for example, a SF network element or a perception service end.
  • the second communication device may request the target service requirement from the data management function network element. Since the data management function network element pre-stores the contract data of the terminal, such as the perception authority of the terminal contract, and other information that can be used to determine the target service requirement, such as a mapping relationship. Therefore, the data management function network element can determine the target service requirement corresponding to the terminal and send it to the second communication device.
  • the perception authority of the terminal includes: the perception authority subscribed by the terminal, the perception notification feedback of the terminal, or the 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.
  • 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.
  • 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.
  • the target service requirement is related to the sensing authority of the terminal.
  • the service requirement request indicates that the terminal allows being sensed
  • the 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.
  • the location information is used to indicate the location of the terminal.
  • the time information of the perception request is used to indicate: the time when the first communication device initiates the perception request or the time when the second communication device receives the perception request.
  • the time information of the service request is used to indicate: 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.
  • the service requirement request carries the perception notification feedback of the terminal
  • the perception notification feedback indicates that the terminal replies to the perception notification request and agrees to be perceived or the terminal has not responded to the perception notification request
  • the perception notification request is used to request the terminal to reply whether it agrees to be perceived
  • determining the target service requirement includes: determining the target service requirement based on the terminal's perception authority, perception notification feedback and a mapping relationship, the mapping relationship including a correspondence between at least one combination of perception authority and perception notification feedback and at least one service requirement.
  • the above mapping relationship corresponds to a terminal.
  • mapping relationship corresponds to the requested service type.
  • mapping relationship corresponds to the terminal and the requested service type.
  • the method 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 for a 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 for the perception request, or denial of authorization for the perception request.
  • the data management function network element can preliminarily screen the perception request according to the perception authority signed by the terminal, so that the perception request for the terminal that is not allowed to be perceived is directly rejected without having to be sent to the second communication device. This can reduce the signaling overhead caused by the subsequent sending of the perception request to the second communication device, the processing volume caused by the second communication device determining whether the terminal is allowed to be perceived, and the signaling overhead and processing volume caused by obtaining the target service requirements.
  • the perception authorization reply indicates authorization of the perception request
  • 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.
  • the data management function network element determines that the perception request is authorized, it can 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 multiplexed, thereby reducing signaling overhead.
  • the awareness authorization reply indicates a denial of the awareness request authorization, and the awareness authorization reply indicates a reason for the denial.
  • the reason for the rejection is also indicated to the third communication device through the perception authorization reply, so that the third communication device can provide the reason for the rejection to the first communication device, for example, the reason for the rejection is that the terminal is not allowed to be perceived. This can avoid the first communication device from initiating a perception request for the terminal again, reducing signaling overhead.
  • a perception method is provided, which can be applied to a data management function network element (such as a UDM), and 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 that can implement all or part of the functions of the communication device.
  • 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 that can implement all or part of the functions of the communication device. This application does not limit this.
  • the method includes: receiving a perception authorization request, the perception authorization request is used to request authorization for a perception request, the perception request is used to request perception of a terminal; sending a perception authorization reply according to the perception authority contracted by the terminal, the perception authorization reply indicates authorization for the perception request, or denial of authorization for the perception request.
  • the data management function network element can preliminarily screen the perception request according to the perception authority signed by the terminal, so that the perception request for the terminal that is not allowed to be perceived is directly rejected without having to be sent to the second communication device. This can reduce the signaling overhead caused by the subsequent sending of the perception request to the second communication device, the processing volume caused by the second communication device determining whether the terminal is allowed to be perceived, and the signaling overhead and processing volume caused by obtaining the target service requirements.
  • the perception authorization reply indicates the authorization of the perception request
  • the perception authorization reply carries the perception permissions 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.
  • the data management function network element determines that the perception request is authorized, it can 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 multiplexed, thereby reducing signaling overhead.
  • the reason for the rejection is also indicated to the third communication device through the perception authorization reply, so that the third communication device can provide the reason for the rejection to the first communication device, for example, the reason for the rejection is that the terminal is not allowed to be perceived. This can avoid the first communication device from initiating a perception request for the terminal again, reducing signaling overhead.
  • 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 when the terminal replies with agreement or does not reply, or requiring notification of the terminal and allowing perception only when the terminal replies with agreement.
  • a perception method is provided, which can be applied to a first communication device, which can be, for example, an AF network element or an AS, or a server integrating AF and AS functions, or a component configured in an AF network element, AS, or server, such as a processor, a chip, a chip system, etc., or a logic module or software capable of implementing all or part of the functions of the first communication device.
  • a first communication device which can be, for example, an AF network element or an AS, or a server integrating AF and AS functions, or a component configured in an AF network element, AS, or server, such as a processor, a chip, a chip system, etc., or a logic module or software capable of implementing all or part of the functions of the first communication device.
  • a first communication device which can be, for example, an AF network element or an AS, or a server integrating AF and AS functions, or a component configured in an AF network element, AS, or server, such as a processor
  • the method includes: receiving a service requirement confirmation request from a second communication device, the service requirement confirmation request is used to request the adoption of a target service requirement, the target service requirement is different from the requested service requirement; sending a service requirement confirmation reply to the second communication device, the service requirement confirmation reply indicating agreement or disagreement to adopt the target service requirement.
  • the second communication device may further confirm with the first communication device whether to agree to adopt the target service requirement when the target service requirement is different from the requested service requirement.
  • the service requirement confirmation request carries the target service requirement.
  • the first communication device may determine whether to agree to adopt the target service requirement based on the target service requirement carried in the service requirement confirmation request. Therefore, the determination of the target service requirement takes into account the security requirements of the terminal and the requirements of the first communication device, and can provide a better user experience.
  • rejection message is sent by the first communication device when the service requirement confirmation reply indicates that the target service requirement is not agreed to be adopted.
  • the rejection message indicates the reason for the rejection.
  • the reason for rejection is that the first communication device does not agree to adopt the target service requirement.
  • a perception method is provided, which can be applied to a system including a data management function network element and a second communication device.
  • the method includes: a second communication device receives a perception request, the perception request is used to request perception of a terminal; the second communication device obtains a target service requirement from a data management function network element, the target service requirement is used to determine a KPI for perceiving the terminal.
  • the second communication device obtains the target service requirement 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 requirement; the data management function network element sends the target service requirement to the second communication device.
  • the target service requirement carries one or more of the following: location information, time information of a perception request or time information of a 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.
  • the data management function network element may determine the target service requirement based on the area to which the terminal location belongs and a mapping relationship, and the mapping relationship includes a correspondence between at least one service requirement and at least one area.
  • 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, and a mapping relationship, and the mapping relationship includes a correspondence between at least one service requirement and at least one time period.
  • the data management function network element may determine the target service requirement based on the area to which the terminal location belongs, one or more of the time information of the perception request or the time information of the service requirement request, and a mapping relationship, and the mapping relationship includes a correspondence between at least one service requirement and at least one combination of an area and a time period.
  • the method further includes: the second communication device determines that the terminal is allowed to be perceived.
  • 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.
  • the method also includes: the second communication device obtains the perception authority of the terminal contract from the data management function network element.
  • the second communication device obtains the target service requirement 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 has not replied; 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 requirement; the data management function network element sends the target service requirement to the second communication device.
  • the data management function network element determines the target service requirements, including: the data management function network element determines the target service requirements based on a mapping relationship, the mapping relationship including a correspondence between at least one service requirement and at least one combination of one or more of the following: perception authority signed by the terminal, perception notification feedback, terminal location, time information of the perception request, or time information of the service requirement request.
  • a communication device which can implement the perception method described in the first to fourth aspects and any possible implementation of the first to fourth aspects.
  • the device includes one or more corresponding functional units or modules for executing the above method.
  • the functional units or modules included in the device can be implemented by software and/or hardware.
  • the device may further include a memory for storing instructions and data.
  • the memory is coupled to the processor, and when the processor executes the instructions stored in the memory, the methods described in the above aspects may be implemented.
  • the apparatus may further include a communication interface, and the communication interface is used for the apparatus to communicate with other devices.
  • the communication interface may be a transceiver, circuit, bus, module or other types of communication interfaces.
  • a chip system 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 method of the first to fourth aspects, for example, receiving or processing the data and/or information involved in the above-mentioned method.
  • the chip system also includes a memory, which is used to store program instructions and data, and the memory is located inside or outside the processor.
  • the chip system further includes an interface circuit and/or a power supply circuit, wherein the interface circuit is used to transmit data, and the power supply circuit is used to supply power to the chip system.
  • the chip system may be composed of the chip, or may include the chip and other discrete devices.
  • the communication system may be used to implement the method in the fifth aspect and any possible implementation manner of the fifth aspect.
  • a computer-readable storage medium 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 manner of the first to fifth aspects.
  • a computer program product which includes: a computer program (also referred to as code, or instruction), 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.
  • a computer program also referred to as code, or instruction
  • FIG1 is a schematic diagram of two possible architectures in a fifth generation (5G) network
  • FIG3 is a schematic diagram of a base station performing a sensing operation
  • FIG4 is a schematic diagram of parameters of perception accuracy and resolution
  • FIG5 is a schematic flow chart of a sensing method provided in an embodiment of the present application.
  • FIG6 is another schematic flow chart of the sensing method provided in an embodiment of the present application.
  • FIG. 7 is another schematic flow chart of the sensing method provided in an embodiment of the present application.
  • FIG8 is another schematic flow chart of the sensing method provided in the embodiment of the present application.
  • FIG9 is another schematic flow chart of the sensing method provided in an embodiment of the present application.
  • FIG10 is a schematic block diagram of a communication device provided in an embodiment of the present application.
  • LTE long term evolution
  • FDD frequency division duplex
  • TDD LTE time division duplex
  • 5G mobile communication system or new radio access technology (NR).
  • LTE long term evolution
  • FDD frequency division duplex
  • TDD time division duplex
  • 5G mobile communication system may include non-standalone (NSA) and/or standalone (SA).
  • SA standalone
  • the technical solution provided in the present 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.
  • MTC machine type communication
  • LTE-M long term evolution-machine
  • D2D device-to-device
  • M2M machine-to-machine
  • IoT Internet of Things
  • IoT network can include vehicle networking, for example.
  • the technical solution provided in this application can also be applied to future communication systems, such as the sixth generation (6G) mobile communication system. This application does not limit this.
  • 6G sixth generation
  • FIG1 a) and b) respectively show two possible architectures in a 5G network: a converged architecture (see FIG1 a)) and an independent architecture (see FIG1 b)).
  • the difference between the converged architecture and the independent architecture lies in the location of the SF deployment dedicated to the sensing service.
  • a terminal is a device with wireless transceiver functions.
  • the terminal can communicate with one or more core network (CN) devices (or core devices) via the access network device (or access device) in the wireless access network.
  • CN core network
  • Terminal devices can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on the water (such as ships); they can also be deployed in the air (such as airplanes, balloons, and satellites).
  • the terminal in the present application can be a hardware device, or a software function running on dedicated hardware, or a software function running on general-purpose hardware, or a virtualized device, for example, implemented by general-purpose hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions.
  • the general-purpose hardware can be a server, such as a cloud server.
  • RAN is a network composed of multiple RAN nodes, which realizes wireless physical layer functions, resource scheduling and wireless resource management, wireless access control and mobility management functions.
  • 5G-RAN can be connected to the user plane function (UPF) through the user plane interface N3 to transmit the data of the terminal device;
  • 5G-RAN establishes a control plane signaling connection with the access and mobility management function (AMF) through the control plane interface N2 to realize functions such as wireless access bearer control.
  • UPF user plane function
  • AMF access and mobility management function
  • RAN nodes can provide wireless communication functions and services, and connect terminals to wireless networks.
  • RAN nodes can also be called RAN devices, or access network devices, etc.
  • 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 6th generation (6G) mobile communication system, or a base station in a future mobile communication system.
  • eNodeB evolved NodeB
  • AP access point
  • TRP transmission reception point
  • gNB next generation NodeB
  • 6G 6th generation
  • a RAN node may be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a wireless controller in a cloud radio access network (CRAN) scenario.
  • a RAN node may also be a server.
  • the RAN node can be a central 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 can also be included in the same network element, such as a baseband unit (BBU).
  • BBU baseband unit
  • the RU can be included in a radio frequency device or a radio frequency unit, such as a remote radio unit (RRU), an active antenna unit (AAU) or a remote radio head (RRH).
  • 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.
  • O-CU open RAN
  • 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
  • RU may also be called O-RU.
  • CU, CU-CP, CU-UP, DU and RU are used as examples for description in this application.
  • Any unit of CU (or CU-CP, CU-UP), DU and RU in this application may be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.
  • the device for implementing the function of the RAN node may be the RAN node itself; or it may be a device capable of supporting the RAN node to implement the function, such as a chip system, a hardware circuit, a software module, or a hardware circuit plus a software module.
  • the device may be installed in the RAN node or used in conjunction with the RAN node.
  • the device for implementing the function of the RAN node is only described as a RAN node, and the solution of the embodiments of the present application is not limited.
  • the RAN node in the present application may be a hardware device, or a software function running on dedicated hardware, or a software function running on general-purpose hardware, or a virtualized device, for example, implemented by general-purpose hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions.
  • the general-purpose hardware may be a server, for example, a cloud server.
  • UPF is responsible for terminal data packet filtering, data transmission/forwarding, rate control, and billing information generation.
  • 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.
  • the time information for requesting perception may be used for requesting the time for perception, and the time for requesting perception may specifically refer to the time for requesting perception of the terminal, or the time for requesting to initiate a perception process for the terminal.
  • step 502 the NEF obtains authorization for the awareness request from the UDM.
  • step 502 may include the following steps 5021 to 5023:
  • Step 5021 NEF sends a perception authorization request to UDM, where the perception authorization request is used to request UDM to authorize the perception request, or to request UDM to perform an authorization check on the perception request.
  • Step 5022 UDM determines whether the terminal is allowed to be sensed or not based on the sensing authority subscribed by the terminal.
  • 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.
  • 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.
  • the perception authorization request may be the above-mentioned perception request.
  • the perception authorization request is obtained by processing the above-mentioned perception request. This application is not limited to this.
  • UDM can determine whether the terminal is allowed or not to be sensed (i.e., whether the terminal is allowed to be sensed) based on the sensed authority signed by the terminal, and indicate authorization or refusal to authorize the sensed request through a sensed authorization reply.
  • UDM determines that the terminal is allowed to be sensed, it can indicate authorization of the sensed request through a sensed authorization reply, as shown in 5023a in the figure; when it determines that the terminal is not allowed to be sensed, it can indicate refusal to authorize the sensed request through a sensed 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.
  • the perception authorization reply 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.
  • 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.
  • 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 is not limited to this.
  • 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 without a terminal reply, requiring notification of the terminal and allowing perception when the terminal replies with consent or does not reply, or requiring notification of the terminal and allowing perception only when the terminal replies with consent.
  • “need to notify the terminal and allow perception when the terminal replies with consent or does not reply” specifically means: need to notify the terminal, allow perception when the terminal replies with consent or does not reply, and do not allow perception when the terminal replies with disagreement; “need to notify the terminal and allow perception only when the terminal replies with consent” specifically means: need to notify the terminal, allow perception when the terminal replies with consent, and do not allow perception when the terminal replies with disagreement or does not reply.
  • Table 1 shows several possible permissions.
  • the perception authority signed by it is one of the multiple authorities shown in Table 1.
  • the perception authority signed by the terminal may include one of the following multiple authorities: allowing perception, not allowing perception, allowing perception, requiring notification of the terminal but without the terminal replying, requiring notification of the terminal, not allowing perception when the terminal replies with disagreement or no reply, or requiring notification of the terminal, not allowing perception only when the terminal replies with disagreement.
  • “need to notify the terminal, not allowing perception when the terminal replies with disagreement or no reply” specifically means: need to notify the terminal, not allowing perception when the terminal replies with disagreement or the terminal does not reply; “need to notify the terminal, not allowing perception only when the terminal replies with disagreement” specifically means: need to notify the terminal, 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 can also be one of multiple authorities.
  • the perception authority signed by each terminal can be pre-configured in the UDM, for example, indicated by the terminal identifier and the index of the authority included in the perception authority signed by the terminal.
  • the perception authority signed by terminal 1 is to allow perception
  • the perception authority signed by terminal 2 is not to allow perception
  • the perception authority signed by terminal 3 is to allow perception
  • the terminal needs to be notified but no terminal reply is required
  • the perception authority signed by terminal 4 is to require notification of the terminal, and perception is allowed when the terminal replies with consent or no reply
  • the perception authority signed by terminal 5 is to require notification of the terminal, and perception is allowed only when the terminal replies with consent.
  • the perception authority signed by the five terminals can be shown in Table 2.
  • step 5022 if the perception authority signed by the terminal is to allow perception, or to allow perception and the terminal needs to be notified but no terminal reply is required, 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, the UDM can directly determine that the terminal is not allowed to be perceived and can refuse to authorize the perception request.
  • 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 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.
  • 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. If it is determined that the terminal is not allowed to be perceived, the perception request will be rejected.
  • requesting UDM to obtain authorization for the perception request can be regarded as UDM's initial screening of the perception request, and it may not necessarily filter all perception requests initiated for terminals that are not allowed to be perceived. For the sake of brevity below, the description of the same or similar situations is omitted.
  • Table 3 shows the correspondence between different permissions and different locations and different times.
  • the perception permissions signed by the terminal include at least one perception permission corresponding to at least one area
  • UDM since UDM cannot directly interact with the terminal, UDM may be temporarily unable to obtain the location of the terminal, and therefore temporarily unable to 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.
  • UDM can preliminarily screen the perception requests according to the perception rights signed by the terminal, so that the perception requests for terminals that are not allowed to be perceived are directly rejected without having to be sent to SF. This can reduce the signaling overhead caused by sending perception requests to SF in the future, as well as the processing volume caused by SF determining whether the terminal is allowed to be perceived and determining the target service requirements.
  • the UDM may determine the identity of the terminal in the communication system according to the external identity of the terminal, such as the user permanent identifier (SUPI) of the terminal, when determining that the perception request is authorized, and carry the SUPI of the terminal in the perception authorization reply.
  • the above perception authorization reply carries the SUPI of the terminal.
  • the UDM may carry the perception authority signed by the terminal and/or the mapping relationship for determining the target business requirements in the perception authorization reply when determining the authorization of the perception request.
  • 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.
  • the mapping relationship used to determine 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 time periods and areas.
  • the UDM may carry the reason for rejection in the perception authorization reply when determining to reject the authorization of the perception request.
  • the above-mentioned perception authorization reply carries the reason for rejection.
  • the reason for rejecting the perception request is that the terminal is not allowed to be perceived.
  • the perception authorization reply 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 used to determine 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.
  • the NEF may determine whether to continue to send the sensing request to the SF based on the received sensing authorization reply. If the sensing authorization reply indicates that the sensing request is authorized, step 503 may be executed, and the NEF sends the sensing request to the SF; if the sensing authorization reply indicates that the sensing request is rejected, step 504 may be executed, and the NEF sends a rejection message to the AF.
  • step 502 is not necessarily required to be executed.
  • NEF can directly forward the perception request to SF without requesting authorization from UDM.
  • NEF can directly forward the perception request to SF, and this application does not limit this.
  • step 503 the NEF sends a sensing request to the SF.
  • 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.
  • NEF may send the received perception request to UDM before sending the perception request to SF, and then forward it to SF after authorization by UDM.
  • step 503 may be performed after receiving an authorization message from the UDM.
  • the UDM determines that the terminal is allowed to be sensed and sends an authorization message to the NEF.
  • 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 according to 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 signed by the terminal and/or the mapping relationship for determining the target service requirements.
  • the NEF can also carry the perception authority carried in the perception authorization reply and/or the mapping relationship for determining the target service requirements in the perception request and send it to the SF.
  • the perception request sent by the AF in step 501 can also be called the first perception request
  • the perception request sent by the NEF in step 502 can also be called the second perception request.
  • both the first perception request and the second perception request can be used to request perception of the terminal.
  • the terminal identifier carried by the first perception request is the external identifier of the terminal
  • the terminal identifier carried by the second perception request is the SUPI of the terminal
  • the second perception request can also carry the perception authority and/or the mapping relationship for determining the target service requirements.
  • the second perception request carries the SUPI of the terminal, and one or more of the following: the AF identifier, 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.
  • the sensing request received by the SF in step 502 may be a first sensing request or a second sensing request.
  • the first sensing request and the second sensing request are collectively referred to as sensing requests.
  • the NEF can 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.
  • step 504 the NEF sends a rejection message to the AF, where the rejection message is used to reject the sensing request.
  • a rejection message may be sent to the AF to reject the perception request.
  • the rejection message may indicate the reason for rejecting the perception request.
  • the reason for the rejection may be obtained from the perception authorization reply from the UDM, or may be determined by the NEF itself, and this application does not limit this.
  • the NEF may forward the perception authorization reply received from the UDM directly to the AF, that is, the perception authorization reply and the rejection message may be the same message.
  • the NEF may generate a rejection message based on the perception authorization reply received from the UDM, that is, the perception authorization reply and the rejection message may be different messages.
  • the SF determines whether the terminal is allowed to be perceived.
  • 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.
  • 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.
  • the SF may first determine whether the terminal is allowed to be sensed or not (ie, whether the terminal is allowed to be sensed), and then obtain the target service requirements if the terminal is allowed to be sensed.
  • Whether the terminal is allowed or not allowed 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 no further description is given.
  • 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 conjunction 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 requires notification of the terminal but does not require a terminal reply, 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 the UDM or pre-configured in the SF, and this application does not limit this.
  • step 502 the UDM can determine whether the terminal is allowed to be sensed according to the sensing authority signed by the terminal, and step 505 does not need to be executed.
  • the SF may determine whether the terminal is allowed to be sensed according to the perception notification feedback of the terminal.
  • the perception notification feedback may indicate that the terminal replies that it agrees to be perceived, or that it disagrees to be perceived, or that the terminal has not responded.
  • SF may determine that the terminal is allowed to be perceived if the perception notification feedback indicates that the terminal replies that it agrees to be perceived; if the terminal replies that it disagrees to be perceived, it may determine that the terminal is not allowed to be perceived, and if the terminal has not responded, SF may determine whether the terminal is allowed to be perceived in combination with preset rules (for example, the perception authority contracted by the terminal).
  • the perception permission signed by the terminal requires notification of the terminal and allows perception when the terminal replies with consent 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.
  • the terminal's perception notification feedback is used to indicate the terminal's reply content or whether it has replied, but does not mean that the terminal must make a feedback.
  • the terminal's perception notification feedback can be understood as the AMF's response to the perception notification request, combined with whether the terminal replies or the content of the reply.
  • 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;
  • 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.
  • the terminal needs to be notified, and the terminal is allowed to be sensed when it replies to agree or does not reply, and the terminal's perception notification feedback indicates that the terminal replies that it does not agree to be sensed;
  • the terminal needs to be notified and is allowed to be sensed only when the terminal replies with consent, and the terminal's perception notification feedback indicates that the terminal replies that it does not agree to be sensed or the terminal's perception notification feedback indicates that the terminal has not replied;
  • step 508 the SF obtains the target service requirements.
  • the service requirement may be pre-stored in the SF, and the service requirement may be called a default service requirement.
  • the SF may directly determine the target service requirement when the terminal allows being sensed.
  • the time information of the sensing request may be used to indicate one or more of the following: the time when the AF initiates the sensing request, the time when the SF receives the sensing request, or the time of the requested sensing carried in the sensing request.
  • the time indicated by the time information is night 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 business requirement can be determined as a business requirement with lower perception accuracy.
  • the target service requirement may be determined according to the location of the terminal.
  • 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.
  • the target service requirement may be determined based on time information of the sensing request and the location of the terminal.
  • 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.
  • 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.
  • the mapping relationship can be combined to determine it.
  • the mapping relationship may include a correspondence relationship 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.
  • 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.
  • Table 6 shows an example of the third mapping relationship.
  • mapping relationship used to determine the target business requirements described above may include one or more of the first mapping relationship, the second mapping relationship, or the third mapping relationship.
  • present application does not limit the specific form of these mapping relationships, for example, it can be a table, or it can be other forms, such as an enumeration arrangement of different combinations. The present application does not limit this.
  • business requirements A and B in Table 4 can all be regarded as several examples of default business requirements. In other words, there can be one or more default business requirements, and this application does not limit this.
  • SF may send a service requirement confirmation request to AF when the target service requirement is different from the requested service requirement. For example, after obtaining the target service requirement, 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, SF may also determine whether the service requirement needs to be adjusted, such as downgrading or upgrading, directly based on the perceived notification feedback after obtaining the perceived notification feedback in step 5064, that is, determining that the target service requirement is different from the requested service requirement, and it is not necessary to determine it by comparing it with the requested service requirement after obtaining the target service requirement.
  • SF may send a service requirement confirmation request to AF when the target service requirement is different from the requested service requirement. For example, after obtaining the target service requirement, 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, SF may also determine whether the service requirement needs to be adjusted, such as downgrading or upgrading, directly based on the perceived notification feedback after obtaining the perceived
  • the SF may carry the target service requirement in the service requirement confirmation request to request to adopt the target service requirement.
  • the SF may carry the target service requirement in the service requirement confirmation request, and the service requirement request is used to instruct the AF to execute the perception process using a service requirement different from that in the perception request, and is used to request the AF to confirm whether the target service requirement can be used to execute perception.
  • the level of the target business requirement is different from the level of the requested business requirement.
  • the level of the target business requirement is lower than the level of the requested business requirement.
  • the business requirement confirmation request can be understood as a request for AF to confirm whether the execution-aware business requirement can or cannot be downgraded.
  • the business requirement confirmation request can also be called a downgrade confirmation request.
  • the level of the target business requirement is different from the level of the requested business requirement.
  • the level of the target business requirement is higher than the level of the requested business requirement.
  • 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.
  • the level of the business requirement can be determined according to the values of the indicators corresponding to the business requirement.
  • the indicator corresponding to the business requirement can be included in the business requirement, can be indicated by the business requirement, or can be an indicator in the KPI converted from the business requirement, and this application does not limit this.
  • the target service requirement level being lower than the requested service requirement level are as follows: For example, the perceived location accuracy in the indicator corresponding to the target service requirement is 1m, and the perceived location accuracy in the indicator corresponding to the requested service requirement is 1mm. Since the accuracy of 1mm is higher than that of 1m, the target service requirement level can be considered to be lower than the requested service requirement level. For another example, the perceived resolution in the indicator corresponding to the target service requirement is 5m, and the perceived resolution in the indicator corresponding to the requested service requirement is 1m. Since the perceived resolution of 1m is higher than that of 5m, the target service requirement level can be considered to be lower than the requested service requirement level.
  • the maximum perceived service delay in the indicator corresponding to the target service requirement is 0.5ms
  • the maximum perceived service delay in the indicator corresponding to the requested service requirement is 0.2ms. Since the delay of 0.2ms is shorter than that of 0.5ms, the target service requirement level can be considered to be lower than the requested service requirement level.
  • the target service requirement being higher than the requested service requirement are as follows: For example, the perceived location accuracy in the indicator corresponding to the target service requirement is 1mm, and the perceived location accuracy in the indicator corresponding to the requested service requirement is 1m. Since the accuracy of 1mm is higher than that of 1m, the target service requirement can be considered to be higher than the requested service requirement. For another example, the perceived resolution in the indicator corresponding to the target service requirement is 1m, and the perceived resolution in the indicator corresponding to the requested service requirement is 5m. Since the perceived resolution of 1m is higher than that of 5m, the target service requirement can be considered to be higher than the requested service requirement.
  • the maximum perceived service delay in the indicator corresponding to the target service requirement is 0.2ms
  • the maximum perceived service delay in the indicator corresponding to the requested service requirement is 0.5ms. Since the delay of 0.2ms is shorter than that of 0.5ms, the target service requirement can be considered to be higher than the requested service requirement.
  • FIG6 is another schematic flow chart of the perception method provided in an embodiment of the present application. Different from the method 500 shown in FIG5 , the method 600 shown in FIG6 provides another processing logic for obtaining target business requirements. The following description focuses on the steps different from those in the method 500. The same steps as those in the method 500 and the description of the same terms can all be referred to the relevant description in the method 500 above, and will not be repeated.
  • step 604 the NEF sends a rejection message to the AF, where the rejection message is used to reject the sensing request.
  • step 605 the SF obtains the perception authority of the terminal contract.
  • 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.
  • step 606 SF obtains the perception notification feedback of the terminal.
  • SF can obtain the perception notification feedback of the terminal by sending a perception notification request.
  • the perception notification request is used to request the terminal to reply whether it agrees to be perceived.
  • step 606 specifically includes: SF sends a perception notification request; SF obtains the perception notification feedback of the terminal according to the response message of the perception notification request.
  • step 606 shows a possible implementation of step 606 from the perspective of device interaction.
  • step 606 specifically includes the following steps 6061 to 6064:
  • Step 6061 SF sends a perception notification request to AMF.
  • Step 6062 AMF forwards the perception notification request to the terminal to request a response from the terminal.
  • Step 6063 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 the terminal replies that it disagrees and does not perceive, or that the terminal has not replied.
  • step 606 is similar to the specific process of step 506 in method 500, and reference may be made to the relevant description in step 506 of method 500.
  • SF may obtain the target service requirement without determining whether the terminal is allowed to be sensed, and therefore, SF does not need to determine whether the terminal is allowed to be sensed first, but may directly execute step 607.
  • step 607 the SF obtains the target service requirements.
  • 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.
  • This embodiment mainly provides a processing flow for determining the target service requirement according to the perception authority of the terminal.
  • the SF does not need to obtain the target service requirement when determining whether the terminal is allowed to be sensed.
  • the target service requirement is obtained based on the sensing notification feedback of the terminal and/or the sensing authority subscribed by the terminal.
  • step 607 determines the target service requirement.
  • the SF may determine the target service requirement according to the sensing authority subscribed by the terminal and/or the sensing notification feedback of the terminal. In other words, the SF may determine the target service requirement corresponding to the sensing authority subscribed by the terminal and/or the sensing notification feedback.
  • the target service requirement corresponding to the perception authority subscribed by the terminal and/or the perception notification feedback of the terminal can be defined by a mapping relationship.
  • the mapping relationship indicates the correspondence between at least one service requirement and at least one combination of the perception authority subscribed by the terminal and the perception notification feedback of the terminal.
  • the SF can determine the target service requirement based on the above mapping relationship and one or more of the perception authority subscribed by the terminal or the perception notification feedback of the terminal.
  • the mapping relationship includes at least one combination of at least one service requirement and 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 description.
  • Table 8 shows an example of the fourth mapping relationship.
  • the fourth mapping relationship may include one of the multiple groups of corresponding relationships shown in Table 8.
  • the business requirements correspond to the perception authority signed by the terminal, so the target business requirements can be determined according to the perception authority signed by the terminal without combining the perception notification feedback.
  • the fourth mapping relationship can also include a correspondence between the perception notification feedback and the business requirements.
  • the target business requirements can also be determined according to the perception notification feedback of the terminal without combining the perception authority signed by the terminal.
  • SF can further determine the target service requirements in combination with the location and/or time information of the terminal.
  • 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 perception authority of the terminal contract, the perception notification feedback of the terminal, the region, or the time period.
  • the sixth mapping relationship may include one or more groups of corresponding relationships shown in Table 10.
  • the SF determines the target service requirements based on the perception notification feedback of the terminal, the perception authority subscribed by the terminal, the time information of the perception request, and the sixth mapping relationship.
  • the location of the terminal can be obtained by initiating a positioning process for the terminal.
  • the time information of the perception request can be used to indicate: the time when the AF initiates the perception request or the time when the SF receives the perception request.
  • the time when SF receives the perception request belongs to time period C, and the perception authority 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 service requirement is service requirement 1.
  • the mapping relationship may be configured in the SF or pre-configured in the UDM. Accordingly, the SF may obtain the mapping relationship locally or from the UDM.
  • SF sends a service requirement request to UDM, and the service requirement request carries the terminal's perception notification feedback.
  • the time information may be time information of the perception request, which may be used to indicate the time when AF initiates the perception request or the time when SF receives the perception request, or it may be time information of the service requirement request, which may be used to indicate the time when SF sends the service requirement request or the time when UDM receives the service requirement request, etc.
  • step 607a For more specific details about how UDM determines the target service requirements based on the perception notification feedback of the terminal, 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.
  • steps 608 to 611 can be skipped and step 612 can be directly executed, and SF sends a rejection message.
  • 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.
  • step 609 the AF sends a service requirement confirmation reply to the SF, where the service requirement confirmation reply indicates whether or not to agree to adopt the target service requirement.
  • step 610 the SF initiates a perception process for the terminal based on the target service requirement.
  • step 611 the SF sends the sensing result to the AF.
  • step 612 the SF sends a rejection message to the AF, where the rejection message is used to indicate the rejection of the sensing request.
  • step 608 to step 612 please refer to the relevant description of steps 509 to 513 in the above method 500, which will not be repeated here.
  • the SF may also initiate a perception process for the terminal based on the target service requirement without confirming with the AF whether to agree to adopt the target service requirement. In this case, the SF does not have to determine whether the target service requirement is the same as the requested service requirement. In other words, steps 609 to 610 are optional steps and do not have to be performed.
  • SF when 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 perceiving the terminal directly according to the service requirements requested by the AF network element or AS.
  • the present application can be related to the perception authority of the terminal, and the target service requirements are obtained with the terminal as the granularity. Therefore, the network side takes into account the security requirements of different terminals, and flexibly responds to the perception request according to the security requirements of different terminals, rather than blindly perceiving without distinguishing the terminal according to the perception request of AF.
  • SF can determine the target service requirements according to the terminal requested to be perceived and the location of the terminal, the time of the requested perception, the requested service type, and other factors, so that the network can use different service requirements to perceive the terminal in different areas, different time periods, and different service types, thereby providing a more flexible network open capability.
  • step 603 and step 604 can be executed alternatively
  • steps 610 to 611 and step 612 can be executed alternatively
  • step 607a and step 607b can be executed alternatively
  • serial number of each step does not mean the order of execution.
  • the execution order of each step should be determined by its function and internal logic.
  • the target service requirement can be determined when the terminal allows being perceived, or it can be determined based on the perception authority subscribed by the terminal and the perception notification feedback of the terminal, and whether the terminal allows or does not allow being perceived is determined based on the perception authority subscribed by the terminal and/or the perception notification feedback, and whether the terminal allows or does not allow being perceived can be indicated by the perception authority of the terminal. Therefore, in general, the target service requirement is related to the perception authority of the terminal.
  • 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 and located at the upper layer of the protocol stack, and the perception client and the perception client can be understood as a perception service platform located at the upper layer of the protocol stack in the UE, and the user plane interaction can be realized between the perception server and the perception client.
  • the perception server can be regarded as a functional network element for docking with external applications (such as AF or AS), and the user plane interaction can also be realized between the perception server and the AS.
  • 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 need for external applications (such as AF or AS) to split their perception requests 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.
  • the perception server is used to receive the perception requirements of the external application (AF or AS), and further interact with the network and UE according to the perception requirements and feedback the perception results.
  • the perception server can be used to implement the SF part 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.
  • the following is explained in conjunction with Figures 7 and 8.
  • FIG7 is another schematic flow chart of the perception method provided in an embodiment of the present application.
  • FIG7 is similar to the processing flow of method 500 shown in FIG5 , and the same or similar steps as those in method 500 and the description of the same terms can refer to the relevant description in method 500 above, and will not be repeated here.
  • the method 700 may include steps 701 to 713. Each step in the method 700 is described in detail below.
  • 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.
  • the AS can interact with the perception server on the user plane, so the first perception request is a user plane message.
  • 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.
  • 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.
  • the method further includes step 705: the perception server obtains perception notification feedback from the terminal.
  • the perception server can interact with the perception client installed in the terminal on the user plane without having to interact through the AMF and RAN nodes. Therefore, the perception server can send the perception notification request to the perception client and receive a response message to the perception notification request from the perception client.
  • step 705 includes the following steps 7051 to 7054:
  • Step 7051 The perception server sends a perception notification request to the perception client.
  • 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 which 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.
  • step 7052 does not necessarily have to be executed, and the perception server can obtain perception notification feedback based on the response message to the perception notification request from the perception client, which may specifically 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.
  • step 706 the perception server obtains the target service requirement.
  • step 706 includes: the perception server determines target business requirements.
  • the target service requirement may be determined based on the time information of the first perception request and/or the location of the terminal.
  • the perception service end may determine the target service requirement based on the time information of the first perception request and/or the location of the terminal.
  • 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.
  • step 709 the perception server sends a second perception request to the SF, and the second perception request carries the target service requirements.
  • the perception server may process the first perception request received in step 701 to obtain a second perception requirement.
  • the perception server may replace the external identifier of the terminal in the first perception request with the SUPI of the terminal, and may carry the target service requirement in the second perception request.
  • the second perception request carries the SUPI of the terminal and the target service requirement, as well as one or more of the following: the identifier of the AS or the requested service type.
  • step 710 the SF initiates a perception process for the terminal based on the target service requirement.
  • the SF may initiate a perception process for the terminal based on the target service requirements carried therein.
  • step 511 of method 500 For the specific content of the SF initiating the perception process of the terminal based on the target service requirements, please refer to the relevant instructions in step 511 of method 500, which will not be repeated here.
  • step 711 SF sends the perception result to the perception server.
  • SF After completing the perception process of the terminal, SF can send the perception result to the perception server.
  • step 712 the perception server sends the perception result to the AS.
  • the perception server can send the perception result to the AS through the user plane.
  • step 713 the perception server sends a rejection message to the AS.
  • Step 8042 The perception client sends a response message to the perception server for the perception notification request, and the response message to the perception notification request carries the perception notification feedback.
  • Step 8043 The perception server obtains perception notification feedback according to the response message of the perception notification request.
  • step 804 For a more detailed description of step 804, please refer to the relevant content of step 704 of method 700, which will not be repeated here.
  • step 805 the perception server obtains the target service requirements.
  • 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.
  • One processing logic is to obtain the target service requirement when determining that the terminal is allowed to be sensed.
  • the method further includes step 903: the second communication device determines that the terminal is allowed to be sensed.
  • the second communication device can determine that the terminal is allowed to be sensed based on the sensed authority subscribed by the terminal and/or the sensed notification feedback of the terminal.
  • the second communication device can determine the target service requirements by itself, as shown in 902a in the figure, or the data management function network element can send a service requirement request, which carries the perception notification feedback and is used to request to obtain 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 authority and/or perception notification feedback signed by the terminal. Furthermore, the target service requirements can also be determined in combination with the location and/or time information of the terminal.
  • step 902 may correspond to step 607 in the above method 600 or step 805 in the above method 800. Therefore, the specific process of step 903 can refer to the relevant description of the corresponding steps in the above method 600 or 800, and will not be repeated here.
  • 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 separately or in combination.
  • 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.
  • 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.
  • the method further includes step 904, obtaining the perception notification feedback of the terminal, the perception notification feedback indicating that the terminal replies to agree to be perceived, the terminal replies to disagree to be perceived, or the terminal does not reply.
  • the second communication device can obtain the perception notification feedback of the terminal by sending a perception notification request.
  • 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 service requirement requested in the perception request.
  • the method further includes step 906, the first communication device sends a service requirement confirmation reply to the second communication device, the service requirement confirmation reply is used to indicate whether to agree or disagree to adopt the target service requirement. Accordingly, the second communication device receives the service requirement confirmation reply from the first communication device.
  • the method further includes step 907, where the second communication device initiates a perception process for the terminal based on the target service requirement.
  • the second communication device may initiate a perception process for the terminal based on the target service requirement.
  • the method further includes step 908, the second communication device sends the sensing result to the first communication device.
  • the first communication device receives the sensing result from the second communication device.
  • the second communication device may send the perception result to the first communication device.
  • the method further includes step 909, the second communication device sends a rejection message to the first communication device, the rejection message is used to reject the sensing request of the first communication device.
  • the first communication device receives the rejection message from the second communication device.
  • the second communication device may reject the sensing request.
  • 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.
  • 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 according to the business requirements requested by the AF network element or AS.
  • 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.
  • the communication unit 1020 is further used to receive the mapping relationship from the data management function network element.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

提供一种感知方法、通信装置和系统。该方法中，负责感知管理功能的网元，比如SF或感知服务端，接收到感知请求后，根据感知请求获取目标业务要求，该目标业务要求用于确定对终端进行感知的KPI，且该目标业务要求的确定与该终端的感知权限相关。SF或感知服务端还可以在目标业务要求与感知请求中携带的业务要求不同时，向外部服务器(比如AS或AF)确认是否同意采用目标业务要求，继而在同意的情况下基于目标业务要求发起对终端的感知流程。该方法结合了终端的感知权限来获取目标业务要求，因此可以灵活地根据终端设备的安全需求来对感知请求消息做出响应，满足不同终端设备的安全需求。

Description

感知方法、通信装置和系统
本申请要求于2024年01月12日提交中国专利局、申请号为202410053504.3、申请名称为“感知方法、通信装置和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种感知方法、通信装置和系统。
背景技术
在移动通信网络中，无线接入网(radio access network，RAN)中的一些基站或终端因拥有电磁波所带来的感知能力，可用作感知节点。感知的实现与雷达的原理相似。即，发射机发射电磁波，电磁波经需要感知的物体反射后由接收机获取，接收机可进一步根据获取的反射信号(可以称为感知原始数据(sensing raw data))处理得到感知数据，该感知数据可以用来获取感知结果。上述发射机和接收机都可称为感知节点。
在目前的感知流程中，感知应用的应用功能(application function，AF)网元或应用服务器(application server，AS)可以向网络能力开放功能(network exposure function，NEF)网元发送感知请求，以请求对特定的终端进行感知，AF、AS或终端也可直接向通信网络中负责感知功能的网元发送感知请求。响应于该感知请求，通信网络中负责感知功能的网元可以发起对特定的终端的感知流程。
目前针对特定终端的感知流程，暂无相关安全的流程。
发明内容
本申请提供一种感知方法、通信装置和系统，以期灵活地根据终端设备的安全需求来对感知请求消息做出响应，满足不同终端设备的安全需求。
第一方面，提供一种感知方法，该方法可应用于第二通信装置，该第二通信装置例如可以是感知功能(sensing function，SF)网元或者感知服务端(sensing server)，也可以是配置在SF网元或感知服务端中的组件，比如处理器、芯片、芯片系统等，还可以是能够实现该第二通信装置全部或部分功能的逻辑模块或软件。本申请对此不作限定。
该方法包括：接收感知请求，该感知请求用于请求对终端进行感知；获取目标业务要求，该目标业务要求用于确定对终端进行感知的关键性能指标(key performance indicator，KPI)，该目标业务要求与该终端的感知权限相关，该感知权限用于确定该终端允许或不允许被感知。
该感知请求例如可以是来自第一通信装置(比如AF网元或AS)的感知请求，可用于请求对一个或多个终端进行感知。本文中为方便理解和说明，以请求对一个终端进行感知为例来描述本申请提供的方法。该终端可以是被请求感知的任意一个终端。
在本申请提供的方案中，用于确定对终端进行感知的KPI的目标业务要求与终端的感知权限相关，从而使得对于终端发起的感知流程是与终端的感知权限相适应的，而不是盲目地直接根据AF网元或AS等请求的业务要求来确定对终端进行感知的KPI。又或者说，本申请可以以终端为粒度来获取目标业务要求。具体地，不同终端的目标业务要求可以根据各自对应的感知权限来确定。因此，考虑到不同终端的安全需求，灵活地根据不同终端的感知权限，获取不同的目标业务要求，进而基于不同的KPI对不同的终端发起感知流程，而不是盲目地根据AF网元或AS请求的业务要求，采用相同的KPI对所有被请求感知的终端进行感知。
可选地，终端的感知权限包括：终端签约的感知权限、终端的感知通知反馈，或由终端签约的感知权限和终端的感知通知反馈确定的终端是否允许被感知的结果。
终端签约的感知权限或终端反馈的感知权限可指示终端允许或不允许被感知，也可用于结合使用，以确定该终端允许或不允许被感知。
其中，终端签约的感知权限为终端与网络运营商签约的感知权限，也可以称配置的感知权限，或默认的感知权限，或网络侧存储的感知权限。例如，终端可通过与运营商签约来明确自身是否允许被感知。
示例性地，该终端签约的感知权限包括如下一种或多种：不允许被感知，允许被感知，或者允许被感知、需要通知终端(但无需终端回复)等。
不难看出，该终端签约的感知权限可指示终端允许或不允许被感知。
终端的感知通知反馈用于指示终端针对接收到的感知通知请求做出的回复，可用于指示终端回复同意或不同意被感知，进而可用于确定终端允许或不允许被感知，因此也可以称之为终端反馈的感知权限。例如，接收到感知请求的第二通信装置可以向终端发送感知通知请求，该感知通知请求可以用于请求终端回复是否同意被感知。
在有些情况下，单纯地根据终端签约的感知权限或终端的感知通知反馈可能无法确定终端是否允许被感知，而需要将二者结合来确定。
示例性地，该终端签约的感知权限为：需要通知终端、在终端回复同意或未回复的情况下允许被感知，或，需要通知终端，仅在终端回复同意的情况下允许被感知。
其中，“需要通知终端、在终端回复同意或未回复的情况下允许被感知”具体为：需要通知终端，在终端回复同意或终端未回复的情况下允许被感知，在终端回复不同意的情况下不允许被感知；“需要通知终端、仅在终端回复同意的情况下允许被感知”具体为：需要通知终端、在终端回复同意的情况下允许被感知，在终端回复不同意或终端未回复的情况下不允许被感知。
终端是否允许被感知可以根据终端针对接收到的感知通知请求是否作出回复或回复的内容而确定。例如，接收到感知请求的第二通信装置可以根据该终端签约的感知权限，向终端发送感知通知请求，该感知通知请求可用于请求终端回复是否同意被感知。终端可以对感知通知请求回复同意或回复不同意，即，该终端的感知通知反馈指示终端回复同意被感知，相应地，该终端的感知权限指示允许被感知，或者，该终端的感知通知反馈指示终端回复不同意被感知，相应地，该终端的感知权限指示不允许被感知。终端也可以对感知通知请求不作回复，即，该终端的感知通知反馈指示终端未回复，此时可结合该终端签约的感知权限来确定：若终端签约的感知权限为需要通知终端、在终端回复同意或未回复的情况下允许被感知，则该终端的感知权限指示终端允许被感知；若该终端签约的感知权限为需要通知终端、仅在终端回复同意的情况下允许被感知，则该终端的感知权限指示终端不允许被感知。
综上可知，终端允许或不允许被感知的结果根据终端签约的感知权限和/或终端的感知通知反馈确定。
结合第一方面，在第一方面的某些可能的实现方式中，终端签约的感知权限包括如下一种或多种：允许被感知，不允许被感知，允许被感知、需要通知终端但无需终端回复，需要通知终端、在终端回复同意或未回复的情况下允许被感知，或者需要通知终端、仅在终端回复同意的情况下允许被感知。
这几种不同的感知权限可以满足不同终端不同的安全需求，这使得网络(比如SF或感知服务端)可以根据不同的安全需求灵活地做出响应。
当然，这些列举仅为示例，终端签约的感知权限可以为上文所列举的任意一项，或者也可以为其他权限，本申请包含但不限于此。
进一步地，终端签约的感知权限可以与至少一个区域对应，和/或，终端签约的感知权限可以与至少一个时段对应。
终端签约的感知权限可以因位置和/或时间的不同而不同。比如，终端签约的感知权限在区域1与在区域2不同，或者，终端签约的感知权限在时段1和时段2不同，等等，不再列举。
通过对同一终端在不同位置和/或不同时段的感知权限，可以进一步满足终端的安全需求，使得第二通信装置更为灵活地根据终端的感知权限对感知请求做出响应。
结合第一方面，在某些可能的实现方式中，该目标业务要求与终端的感知权限相关，包括：该目标业务要求是在确定该终端允许被感知的情况下获取的，和/或，该目标业务要求是根据终端的感知权限确定的。
其中，该目标业务要求是在确定终端允许被感知的情况下获取的，也即，在确定终端允许被感知的情况下，获取目标业务要求；在确定终端不允许被感知的情况下，不获取目标业务要求。而终端允许或不允许被感知由终端的感知权限确定，或者说为终端的感知权限，因此，目标业务要求与终端的感知权限相关。
相应地，所述获取目标业务要求，包括：在确定终端允许被感知的情况下，获取目标业务要求。
其中，确定终端允许被感知，也就是，由终端的感知权限确定该终端允许被感知，或者说，该终端的感知权限指示终端允许被感知。
可选地，所述确定终端允许被感知，包括：根据终端签约的感知权限和/或感知通知反馈，确定终端允许被感知，该感知通知反馈指示终端回复同意被感知或终端未回复。
换言之，终端允许或不允许被感知可以根据签约的感知权限和/或终端的感知通知反馈确定。
应理解，上文针对终端的感知权限已经详细说明了确定终端是否允许被感知的几种可能的实现方式，确定终端允许被感知的具体实现方式可参看上文，不再赘述。
进一步地，所述方法还包括：发送感知通知请求，该感知通知请求用于请求终端回复同意或不同意被感知；根据该感知通知请求的响应消息获得该感知通知反馈。
即，通过向终端发送感知通知请求来获得终端的感知通知反馈。该感知通知请求的响应消息可以是针对该感知通知请求的响应消息，可用于指示该感知通知反馈。一种可能的设计是，该感知通知请求的响应消息中携带该感知通知反馈。
终端签约的感知权限可以是从数据管理功能网元获取的，也可以是预配置在第二通信装置中的，本申请对此不作限定。如果该终端签约的感知权限是从数据管理功能网元获取的，可选地，该方法还包括：从数据管理功能网元获取所述终端签约的感知权限。
目标业务要求是根据终端的感知权限确定的，可以包括：目标业务要求是根据终端签约的感知权限和/或终端的感知通知反馈确定的，或者，目标业务要求是根据终端允许被感知的结果确定的，而终端允许被感知的结果根据终端签约的感知权限和/或终端的感知通知反馈确定。因此，可替换地，目标业务要求是根据终端签约的感知权限和/或感知通知反馈确定的。
目标业务要求可以由数据管理功能网元(比如统一数据管理(unified data management，UDM)网元)确定，进而发送给第二通信装置；也可以由第二通信装置确定。
目标业务要求可以在确定终端允许被感知的情况下获取，也可以在未确定终端允许被感知的情况下获取，下文提供了多种可能的实现方式。
在一种可能的实现方式中，该目标业务要求是从数据管理功能网元获取到的。
可选地，所述在确定终端允许被感知的情况下，获取目标业务要求，包括：在确定终端允许被感知的情况下，向数据管理功能网元发送业务要求请求；接收来自数据管理功能网元的目标业务要求，该目标业务要求基于该业务要求请求确定。
一种可能的情况是，该业务要求请求可以是在第二通信装置确定终端允许被感知的情况下，向数据管理功能网元发送的，换言之，该业务要求请求的发送可以是终端允许被感知这一条件触发的。数据管理功能网元可以在接收到该业务要求请求后，确定目标业务要求，并发送给第二通信装置。也就是说，该业务要求请求的发送可用于隐式地指示该终端允许被感知。数据管理功能网元接收到该业务要求请求，便可默认该终端允许被感知。
另一种可能的情况是，该业务要求请求也可以是在第二通信装置确定终端是否允许被感知的结果的情况下发送的，并可通过该业务要求请求指示终端允许或不允许被感知。换言之，不管终端是否允许被感知，第二通信装置都可以向数据管理功能网元发送该业务要求请求。数据管理功能网元可以根据接收到的业务要求请求，先确定终端是否允许被感知，在终端允许被感知的情况下确定并向第二通信装置发送目标业务要求，而在终端不允许被感知的情况下不必确定目标业务要求。也就是说，数据管理功能网元并不一定要确定和发送目标业务要求。
可选地，该业务要求请求中携带感知通知反馈，该感知通知反馈指示终端对感知通知请求回复同意被感知或终端未回复，该感知通知请求用于请求终端回复同意或不同意被感知。
也即，在未确定终端允许被感知的情况下，通过业务要求请求从数据管理功能网元获取目标业务要求。该业务要求请求中携带感知通知反馈，也即，第二通信装置将感知通知反馈直接告知数据管理功能网元，由数据管理功能网元根据该感知通知反馈和终端签约的感知权限来确定目标业务要求。而数据管理功能网元可以在确定出终端允许被感知的情况下进一步确定目标业务要求，也可以直接根据该终端签约的感知权限和感知通知反馈，确定目标业务要求。
进一步地，该方法还包括：发送感知通知请求，该感知通知请求用于请求该终端回复是否同意被感知；根据感知通知请求的响应消息获取该感知通知反馈。
也即，通过向终端发送感知通知请求，来获取该终端的感知通知反馈。
可选地，该业务要求请求还包括终端的位置信息和/或感知请求的时间信息。其中，终端的位置信息用于指示终端的位置。该位置信息例如可以携带在该业务要求请求中。
感知请求的时间信息用于指示如下一项或多项：第一通信装置发起感知请求的时间、第二通信装置接收到感知请求的时间、该感知请求指示的请求感知的时间、或者数据管理功能网元接收到业务要求请求的时间。该时间信息例如可以携带在该业务要求请求中，也可以由数据管理功能网元根据接收到该业务要求请求的时间确定，本申请对此不作限定。
通过在业务要求请求中携带终端的位置信息和/或感知请求的时间信息，使得目标业务要求的确定还可进一步结合位置信息和/或位置信息来确定。
综上不难看出，该目标业务要求可以基于业务要求请求中携带的信元(information element，IE)和/或时间信息中的一项或多项确定。其中，所述信元包括如下一项或多项：终端签约的感知权限、终端允许被感知的指示、感知通知反馈、位置信息、发起感知请求的时间或接收到感知请求的时间。
在另一种可能的实现方式中，该目标业务要求是第二通信装置确定的。
可选地，所述在确定终端允许被感知的情况下，获取目标业务要求，包括：在确定终端允许被感知的情况下，根据该终端的位置和/或感知请求的时间信息，确定目标业务要求。
也即，在确定终端允许被感知的情况下，第二通信装置自行确定目标业务要求。
在不区分终端的位置和感知请求的时间信息的情况下，第二通信装置可以在终端允许被感知的情况下直接确定出目标业务要求。但本申请并不限于，第二通信装置也可以基于终端的位置或感知请求的时间信息，确定目标业务要求。
其中，感知请求的时间信息用于指示如下一项或多项：第一通信装置发起感知请求的时间、第二通信装置接收到感知请求的时间或该感知请求指示的请求感知的时间。
在具体实现中，第二通信装置可以根据映射关系，以及终端的位置所属的区域确定目标业务要求，该映射关系包括至少一种业务要求与至少一个区域之间的对应关系。或者，第二通信装置可以根据映射关系，感知请求的时间信息确定目标业务要求，该映射关系包括至少一种业务要求与至少一个时段之间的对应关系。或，第二通信装置可以根据映射关系，感知请求的时间信息和终端的位置所属的区域，确定目标业务要求，该映射关系包括至少一种业务要求与区域和时段的至少一种组合的对应关系。
可选地，所述获取目标业务要求，包括：根据终端签约的感知权限、感知通知反馈和映射关系，确定目标业务要求，该感知通知反馈指示终端对感知通知请求回复同意被感知或终端对所述感知通知请求未回复，该感知通知请求用于请求终端回复是否同意被感知，该映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
也即，在未确定终端允许被感知的情况下，第二通信装置也可以根据终端签约的感知权限、感知通知反馈和映射关系，直接确定出目标业务要求。
可以理解的是，在未确定终端允许被感知的情况下，也有可能获取不到目标业务要求，此时可以将目标业务要求视为拒绝感知请求，或者说，将拒绝感知请求视为目标业务要求的一种。
该映射关系可以是从数据管理功能网元接收到的，也可以是预配置在第二通信装置中的，本申请对此不作限定。如果是从数据管理功能网元接收到的，可选地，该方法还包括：接收来自数据管理功能网元的映射关系。
进一步地，上述映射关系中，感知权限和感知通知反馈的至少一种组合中的每种组合可以与一种或多种业务要求对应，该一种或多种业务要求与一个或多个区域对应。相应地，所述根据终端签约的感知权限、感知通知反馈和映射关系，确定目标业务要求，包括：根据终端签约的感知权限、感知通知反馈、终端的位置所属的区域和映射关系，确定目标业务要求。
也即，终端在不同的区域可以具有不同的业务要求，第二通信装置可以进一步结合终端的位置所属的区域来确定目标业务要求。
或者，上述映射关系中，感知权限和感知通知反馈的至少一种组合中的每种组合可以与一种或多种业务要求对应，该一种或多种业务要求与一个或多个时段对应。相应地，所述根据终端签约的感知权限、感知通知反馈和映射关系，确定目标业务要求，包括：根据终端签约的感知权限、感知通知反馈、感知请求的时间信息和映射关系，确定目标业务要求。
如前所述，该感知请求的时间信息用于指示如下一项或多项：第一通信装置发起感知请求的时间、第二通信装置接收到感知请求的时间或感知请求指示的请求感知的时间。
也即，在不同的时段，终端也可以具有不同的业务要求，第二通信装置可以进一步结合发起或接收到感知请求的时间或请求感知的时间所属的时段，来确定目标业务要求。
综上可以看到，目标业务要求可以根据终端的感知权限、感知通知反馈、终端的位置、或时间信息中的一项或多项来确定。换言之，目标业务要求可以根据映射关系确定，该映射关系可以包括至少一种业务要求与如下一项或多项的至少一种组合的对应关系：终端签约的感知权限、感知通知反馈、区域或时段。
通过上文提供的确定目标业务要求的多种可能的实现方式可知，不论是在确定终端允许被感知的情况下获取目标业务要求，还是在未确定终端允许被感知的情况下获取目标业务要求，该目标业务要求都与该终端的感知权限相关。具体来说，终端允许被感知需要根据该终端签约的感知权限和/或终端的感知通知反馈来确定，即便是在未确定终端是否允许被感知的情况下获取目标业务要求，该目标业务要求还需根据终端签约的感知权限和终端的感知通知反馈来确定。因此，总体来说，该目标业务要求与该终端的感知权限相关。
此外，目标业务要求的确定还可以结合终端的位置和/或时间信息来确定，从而可以为感知请求提供更丰富的业务要求，满足终端的安全需求。
可选地，上述映射关系与终端对应。
也即，对应于同一种业务类型、不同的终端的映射关系可以相同或不同。
上述感知请求还携带请求感知的终端的标识。该映射关系可以是从预配置的、与至少一个终端对应的至少一组映射关系中确定的、与该终端对应的一组映射关系。
在一种可能的设计中，上述映射关系是预配置在第二通信装置中的。
在另一种可能的设计中，上述映射关系是从数据管理功能网元获取到的。相应地，该方法还包括：接收来自数据管理功能网元的映射关系。
以终端为粒度来定义不同终端与不同业务要求的对应关系，可以满足不同终端的安全需求。
可选地，上述映射关系与请求的业务类型对应。
也即，对应于同一个终端、不同的业务类型的映射关系可以相同或不同。
上述感知请求还指示请求的业务类型。该映射关系可以是从预配置的、与至少一种业务类型对应的至少一组映射关系中确定的与请求的业务类型对应的一组映射关系。
以业务类型为粒度来定义不同业务类型与不同业务要求的对应关系，可以满足不同的业务需求。
可选地，上述映射关系与终端和请求的业务类型对应。
也即，上述映射关系可以是从预配置的、与至少一个终端和至少一种业务类型对应的多组映射关系中确定的、与该终端和请求的业务类型对应的一组映射关系。
通过对不同的终端和不同的业务类型定义与不同的业务要求的对应关系，既考虑到不同终端的安全需求，又考虑到不同的业务需求，从而可以更灵活地对感知请求做出响应。
结合第一方面，在第一方面的某些可能的实现方式中，所述感知请求来自第一通信装置，该感知请求中还携带请求的业务要求，该方法还包括：向第一通信装置发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求，该目标业务要求与请求的业务要求不同；接收来自第一通信装置的业务要求确认回复，该业务要求确认回复指示同意或不同意采用该目标业务要求；在业务要求确认回复指示同意采用目标业务要求的情况下，基于目标业务要求发起对终端的感知流程；或，在业务要求确认回复指示不同意采用目标业务要求的情况下，向第一通信装置发送拒绝消息，该拒绝消息用于拒绝感知请求。
第二通信装置可以在目标业务要求与请求的业务要求不同的情况下，进一步与第一通信装置确认是否同意采用目标业务要求。
一种可能的情况是，所述向第一通信装置发送业务要求确认请求，包括：在目标业务要求的级别低于请求的业务要求的情况下，向第一通信装置发送业务要求确认请求。
也就是说，在业务要求降级的情况下，进一步与第一通信装置确认是否同意降级。
另一种可能的情况是，所述向第一通信装置发送业务要求确认请求，包括：在目标业务要求的级别高于请求的业务要求的情况下，向第一通信装置发送业务要求确认请求。
也就是说，在业务要求升级的情况下，进一步与第一通信装置确认是否同意升级。
综上可以看到，该目标业务要求的确定兼顾了终端的安全需求和第一通信装置的需求，可以提供较好的使用体验。
可选地，该方法还包括：在确定终端不允许被感知的情况下，向第一通信装置发送拒绝消息，该拒绝消息用于拒绝感知请求。
终端不允许被感知在上文已经结合终端的感知权限做了详细说明，不再赘述。
该拒绝消息与上文中第二通信装置在第一通信装置不同意采用目标业务要求的情况下发送的拒绝消息可以是具有相同功能的消息，只是触发第二通信装置发送拒绝消息的原因不同，二者可以择一发送。
进一步地，该拒绝消息中携带拒绝感知请求的原因。
示例性地，拒绝感知请求的原因可以是终端不允许被感知，或者，第一通信装置不同意采用目标业务要求，等等，不再列举。
第二方面，提供了一种感知方法，该方法可应用于数据管理功能网元(比如UDM)，该方法的执行主体例如可以是数据管理功能网元，也可以是配置在数据管理功能网元中的组件，比如处理器、芯片、芯片系统等，还可以是能够实现该通信装置全部或部分功能的逻辑模块或软件。本申请对此不作限定。
该方法包括：接收来自第二通信装置的业务要求请求，该业务要求请求用于请求获取目标业务要求，该目标业务要求用于确定对终端进行感知的KPI；确定目标业务要求，该目标业务要求与终端的感知权限相关，该终端的感知权限用于确定终端允许或不允许被感知；向第二通信装置发送该目标业务要求。
在本方案中，第二通信装置例如可以是SF网元或感知服务端。第二通信装置可以向数据管理功能网元请求目标业务要求。由于数据管理功能网元中预存有终端的签约数据，比如终端签约的感知权限，以及其他可用于确定目标业务要求的信息，比如映射关系。因此数据管理功能网元可以确定出与该终端对应的目标业务要求，并发送给第二通信装置。
可选地，终端的感知权限包括：终端签约的感知权限、终端的感知通知反馈，或由终端签约的感知权限和终端的感知通知反馈确定的终端是否允许被感知的结果。
关于终端的感知权限、终端签约的感知权限、终端的感知通知反馈，以及由终端签约的感知权限和终端的感知通知反馈确定的终端是否允许被感知的结果在第一方面中已经做了详述，可参看第一方面中的相关描述，不再赘述。
可选地，该目标业务要求与终端的感知权限相关，包括：该目标业务要求是在确定该终端允许被感知的情况下获取的，或，该目标业务要求是根据终端的感知权限确定的。
终端允许或不允许被感知由终端的感知权限确定，或者说为终端的感知权限，因此总体来说，目标业务要求与终端的感知权限相关。
关于目标业务要求与终端的感知权限相关的说明可参看第一方面中的相关描述，不再赘述。
结合第二方面，在某些可能的实现方式中，所述业务要求请求指示终端允许被感知，所述确定目标业务要求，包括：将默认的业务要求确定为目标业务要求。其中，默认的业务要求可以为预配置的业务要求，也可以是请求的业务要求，本申请对此不作限定。
也就是说，在终端允许被感知的情况下，直接就可确定出目标业务要求。该目标业务要求的确定较为简单方便。
可选地，所述业务要求请求还携带如下一项或多项：位置信息、感知请求的时间信息或业务要求请求的时间信息，该感知请求用于请求对终端进行感知；所述确定目标业务要求，包括：根据该业务要求请求，确定目标业务要求。
换言之，数据管理功能网元可以根据终端的位置所属的区域，以及映射关系，确定目标业务要求，该映射关系指示至少一种业务要求与至少一个区域之间的对应关系；和/或，数据管理功能网元可以根据感知请求的时间信息或业务要求请求的时间信息中的一项，以及映射关系，确定目标业务要求，该映射关系指示至少一种业务要求与至少一个时段之间的对应关系。
其中，位置信息用于指示终端的位置。感知请求的时间信息用于指示：第一通信装置发起感知请求的时间或第二通信装置接收到感知请求的时间。业务要求请求的时间信息用于指示：第二通信装置发送该业务要求请求的时间或数据管理功能网元接收该业务要求请求的时间。
结合第二方面，在某些可能的实现方式中，所述业务要求请求携带终端的感知通知反馈，该感知通知反馈指示终端对感知通知请求回复同意被感知或所述终端对所述感知通知请求未回复，该感知通知请求用于请求所述终端回复是否同意被感知；以及，所述确定所述目标业务要求，包括：根据终端的感知权限、感知通知反馈和映射关系，确定目标业务要求，该映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
也即，在未确定终端允许被感知的情况下，也可以确定目标业务要求。数据管理功能网元可以根据该感知通知反馈和终端签约的感知权限来确定目标业务要求。而数据管理功能网元可以在确定出终端允许被感知的情况下进一步确定目标业务要求，也可以直接根据该终端签约的感知权限和感知通知反馈，确定目标业务要求。
可选地，所述业务要求请求还携带如下一项或多项：位置信息、感知请求的时间信息或业务要求请求的时间信息，该感知请求用于请求对终端进行感知；所述确定目标业务要求，包括：根据该终端的位置和/或感知请求的时间信息，确定目标业务要求。
关于位置信息和时间信息的相关说明可参看上文，不再赘述。
综上不难看出，该目标业务要求可以根据业务要求请求中携带的IE和/或时间信息中的一项或多项确定。其中，所述信元包括如下一项或多项：终端允许被感知的指示、感知通知反馈、位置信息、发起感知请求的时间或接收到感知请求的时间。
或者说，目标业务要求可以根据终端的感知权限、感知通知反馈、终端的位置、或时间信息中的一项或多项来确定。换言之，目标业务要求可以根据映射关系确定，该映射关系可以包括至少一种业务要求与如下一项或多项的至少一种组合的对应关系：终端签约的感知权限、感知通知反馈、区域或时段。
通过上文提供的确定目标业务要求的两种可能的实现方式可知，目标业务要求的确定不仅与终端的感知权限相关，还可以结合终端的位置和/或时间信息来确定，从而可以为感知请求提供更丰富的业务要求，满足终端的安全需求。
可选地，上述映射关系与终端对应。
可选地，上述映射关系与请求的业务类型对应。
可选地，上述映射关系与终端和请求的业务类型对应。
关于映射关系与终端和/或请求的业务类型对应的相关内容在上文第一方面中已经做了详述，可参看第一方面中的相关描述，不再赘述。
结合第二方面，在第二方面的某些可能的实现方式中，在所述接收来自第二通信装置的业务要求请求之前，该方法还包括：接收感知授权请求，该感知授权请求用于请求对感知请求授权，该感知请求用于请求对终端进行感知；根据终端签约的感知权限，发送感知授权回复，该感知授权回复指示对所述感知请求授权，或拒绝对感知请求授权。
数据管理功能网元可以根据终端签约的感知权限，对感知请求进行初筛，使得针对不允许被感知的终端的感知请求直接被拒绝，而不必再发送给第二通信装置。从而可以减少后续给第二通信装置发送感知请求带来的信令开销，第二通信装置确定该终端是否允许被感知带来的处理量，以及获取目标业务要求带来的信令开销和处理量。
可选地，该感知授权回复指示对感知请求授权，该感知授权回复中携带该终端签约的感知权限和/或用于确定目标业务要求的映射关系，该目标业务要求用于确定对终端进行感知的KPI。
数据管理功能网元可以在确定对感知请求授权的情况下，可通过该感知授权回复将终端签约的感知权限和/或映射关系通过第三通信装置转发给第二通信装置，也即，可以复用该感知授权回复和第三通信装置给第二通信装置发送的感知请求，从而可以减少信令开销。
可选地，该感知授权回复指示对拒绝感知请求授权，该感知授权回复指示拒绝的原因。
数据管理功能网元在确定对感知请求拒绝授权的情况下，将拒绝的原因通过感知授权回复也指示给第三通信装置，从而便于第三通信装置向第一通信装置提供拒绝的原因，例如，拒绝的原因为终端不允许被感知。由此可以避免第一通信装置再次发起对该终端的感知请求，减少信令开销。
第三方面，提供了一种感知方法，该方法可应用于数据管理功能网元(比如UDM)，该通信装置例如可以是数据管理功能网元，也可以是配置在数据管理功能网元中的组件，比如处理器、芯片、芯片系统等，还可以是能够实现该通信装置全部或部分功能的逻辑模块或软件。本申请对此不作限定。
该方法包括：接收感知授权请求，所述感知授权请求用于请求对感知请求授权，所述感知请求用于请求对终端进行感知；根据所述终端签约的感知权限，发送感知授权回复，所述感知授权回复指示对所述感知请求授权，或拒绝对所述感知请求授权。
在本方案中，数据管理功能网元可以根据终端签约的感知权限，对感知请求进行初筛，使得针对不允许被感知的终端的感知请求直接被拒绝，而不必再发送给第二通信装置。从而可以减少后续给第二通信装置发送感知请求带来的信令开销，第二通信装置确定该终端是否允许被感知带来的处理量，以及获取目标业务要求带来的信令开销和处理量。
结合第三方面，在某些可能的实现方式中，该感知授权回复指示对感知请求授权，该感知授权回复中携带该终端签约的感知权限和/或用于确定目标业务要求的映射关系，该目标业务要求用于确定对终端进行感知的KPI。
数据管理功能网元可以在确定对感知请求授权的情况下，可通过该感知授权回复将终端签约的感知权限和/或映射关系通过第三通信装置转发给第二通信装置，也即，可以复用该感知授权回复和第三通信装置给第二通信装置发送的感知请求，从而可以减少信令开销。
结合第三方面，在某些可能的实现方式中，该感知授权回复指示拒绝对感知请求授权，该感知授权回复指示拒绝的原因。
数据管理功能网元在确定对感知请求拒绝授权的情况下，将拒绝的原因通过感知授权回复也指示给第三通信装置，从而便于第三通信装置向第一通信装置提供拒绝的原因，例如，拒绝的原因为终端不允许被感知。由此可以避免第一通信装置再次发起对该终端的感知请求，减少信令开销。
结合第二方面或第三方面，在某些可能的实现方式中，终端签约的感知权限包括如下一种或多种：允许被感知，不允许被感知，允许被感知、需要通知终端但无需终端回复，需要通知终端、在终端回复同意或未回复的情况下允许被感知，或者需要通知终端、仅在终端回复同意的情况下允许被感知。
关于终端签约的感知权限的相关说明可参看第一方面中的相关描述，不再赘述。
第四方面，提供了一种感知方法，该方法可应用于第一通信装置，该第一通信装置例如可以是AF网元或AS，或集成了AF和AS功能的服务器，也可以是配置在AF网元、AS或服务器中的组件，比如处理器、芯片、芯片系统等，还可以是能够实现该第一通信装置全部或部分功能的逻辑模块或软件。本申请对此不作限定。
该方法包括：接收来自第二通信装置的业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求，该目标业务要求与请求的业务要求不同；向该第二通信装置发送业务要求确认回复，该业务要求确认回复指示同意或不同意采用该目标业务要求。
第二通信装置可以在目标业务要求与请求的业务要求不同的情况下，进一步与第一通信装置确认是否同意采用目标业务要求。一种可能的实现方式是，该业务要求确认请求中携带目标业务要求。第一通信装置可以根据业务要求确认请求中携带的目标业务要求，来确定是否同意采用该目标业务要求。因此，该目标业务要求的确定兼顾了终端的安全需求和第一通信装置的需求，可以提供较好的使用体验。
结合第四方面，在第四方面的某些可能的实现方式中，该方法还包括：接收来自第二通信装置的拒绝消息，该拒绝消息用于拒绝该感知请求。
可以理解，该拒绝消息是第一通信装置在业务要求确认回复指示不同意采用该目标业务要求的情况下发送的。
可选地，该拒绝消息指示拒绝的原因。
示例性地，拒绝的原因为该第一通信装置不同意采用目标业务要求。
第五方面，提供了一种感知方法，该方法可应用于包括数据管理功能网元和第二通信装置的系统中。
该方法包括：第二通信装置接收感知请求，该感知请求用于请求对终端进行感知；该第二通信装置从数据管理功能网元获取目标业务要求，该目标业务要求用于确定对终端进行感知的KPI。
结合第五方面，在某些可能的实现方式中，该第二通信装置从数据管理功能网元获取目标业务要求，包括：该第二通信装置在确定终端允许被感知的情况下，向数据管理功能网元发送业务要求请求，该业务要求请求指示终端允许被感知；该数据管理功能网元确定目标业务要求；该数据管理功能网元向该第二通信装置发送目标业务要求。
可选地，该目标业务要求中携带如下一项或多项：位置信息、感知请求的时间信息或业务要求的时间信息，该感知请求用于请求对终端进行感知；该数据管理功能网元确定目标业务要求，包括：该数据管理功能网元根据目标业务要求，确定目标业务要求。
在具体实现中，数据管理功能网元可以根据终端的位置所属的区域，以及映射关系，确定目标业务要求，该映射关系包括至少一种业务要求与至少一个区域之间的对应关系。或者，数据管理功能网元可以根据感知请求的时间信息和/或业务要求请求的时间信息中，以及映射关系，确定目标业务要求，该映射关系包括至少一种业务要求与至少一个时段之间的对应关系。或者，数据管理功能网元可以根据终端的位置所属的区域，感知请求的时间信息或业务要求请求的时间信息中的一项或多项，以及映射关系，确定目标业务要求，该映射关系包括至少一种业务要求与区域和时段的至少一种组合的对应关系。
结合第五方面，在某些可能的实现方式中，该方法还包括：第二通信装置确定终端允许被感知。
可选地，所述第二通信装置确定终端允许被感知，包括：第二通信装置根据终端签约的感知权限和/或感知通知反馈，确定终端允许被感知，该感知通知反馈指示终端回复同意被感知或终端未回复。
可选地，该方法还包括：第二通信装置从数据管理功能网元获取该终端签约的感知权限。
结合第五方面，在某些可能的实现方式中，该第二通信装置从数据管理功能网元获取目标业务要求，包括：第二通信装置向终端发送感知通知请求，该感知通知请求用于请求终端回复是否同意被感知；第二通信装置根据感知通知请求的响应消息获取感知通知反馈，该感知通知反馈指示终端回复同意被感知或终端未回复；该第二通信装置向数据管理功能网元发送业务要求请求，该业务要求请求中携带该感知通知反馈；该数据管理功能网元确定目标业务要求；该数据管理功能网元向第二通信装置发送该目标业务要求。
可选地，该数据管理功能网元确定目标业务要求，包括：该数据管理功能网元根据映射关系确定目标业务要求，该映射关系包括至少一种业务要求与如下一项或多项的至少一种组合的对应关系：终端签约的感知权限、感知通知反馈、终端的位置、感知请求的时间信息或业务要求请求的时间信息。
第六方面，提供了一种通信装置，可以实现上述第一至第四方面及第一至第四方面中任一种可能的实现方式中所述的感知方法。该装置包括用于执行上述方法的相应的一种或多种功能单元或模块。该装置包括的功能单元或模块可以通过软件和/或硬件方式实现。
第七方面，提供了一种通信装置，包括处理器，所述处理器用于执行第一至第四方面及第一至第四方面中任一种可能实现方式中所述的感知方法。
可选地，所述装置还可以包括存储器，用于存储指令和数据。所述存储器与所述处理器耦合，所述处理器执行所述存储器中存储的指令时，可以实现上述各方面中描述的方法。
可选地，所述装置还可以包括通信接口，所述通信接口用于该装置与其它设备进行通信，示例性地，通信接口可以是收发器、电路、总线、模块或其它类型的通信接口。
第八方面，提供了一种芯片系统，该芯片系统包括至少一个处理器，用于支持实现上述第一至第四方面及第一至第四方面中任一种可能实现方式中所涉及的功能，例如，例如接收或处理上述方法中所涉及的数据和/或信息。
在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。
在一种可能的设计中，所述芯片系统还包括接口电路和/或供电电路，所述接口电路用于传输数据，所述供电电路用于为所述芯片系统供电。
该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。
第九方面，提供了一种通信系统，该通信系统包括前述的第一通信装置、第二通信装置或数据管理功能网元中的一项或多项。该第二通信装置可用于实现上述第一方面及第一方面任一种可能实现方式中所涉及的功能，该数据管理功能网元可用于实现上述第二或第三方面及第二或第三方面任一种可能实现方式中所涉及的功能，该第一通信装置可用于实现上述第四方面及第四方面任一种可能实现方式中所涉及的功能。
可选地，该通信系统可用于实现上述第五方面及第五方面任一种可能实现方式中的方法。
第十方面，提供了一种计算机可读存储介质，包括计算机程序，当其在计算机上运行时，使得计算机实现第一至第五方面及第一至第五方面中任一种可能实现方式中的方法。
第十一方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行第一至第五方面及第一至第五方面中任一种可能实现方式中的方法。
应当理解的是，本申请的第五方面至第十一方面与本申请的第一方面至第四方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。
附图说明
图1是第五代(5th generation，5G)网络中的两种可能的架构的示意图；
图2是本申请实施例提供的基于服务化架构(serving based architecture，SBA)的网络架构的示意图；
图3是基站执行感知操作的示意图；
图4是感知精度和分辨率的参数示意图；
图5是本申请实施例提供的感知方法的示意性流程图；
图6是本申请实施例提供的感知方法的另一示意性流程图；
图7是本申请实施例提供的感知方法的又一示意性流程图；
图8是本申请实施例提供的感知方法的再一示意性流程图；
图9是本申请实施例提供的感知方法的再一示意性流程图；
图10是本申请实施例提供的通信装置的示意性框图；
图11是本申请实施例提供的通信装置的另一示意性框图。
具体实施方式
下面将结合附图，对本申请提供的技术方案进行描述。
本申请提供的方法可以应用于各种通信系统，例如：长期演进(long term evolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)系统、5G移动通信系统或新无线接入技术(new radio access technology，NR)。其中，5G移动通信系统可以包括非独立组网(non-standalone，NSA)和/或独立组网(standalone，SA)。
本申请提供的技术方案还可以应用于机器类通信(machine type communication，MTC)、机器间通信长期演进技术(long term evolution-machine，LTE-M)、设备到设备(device-to device，D2D)网络、机器到机器(machine to machine，M2M)网络、物联网(internet of things，IoT)网络或者其他网络。其中，IoT网络例如可以包括车联网。其中，车联网系统中的通信方式统称为车到其他设备(vehicle to X，V2X，X可以代表任何事物)系统，例如，该V2X可以包括：车辆到车辆(vehicle to vehicle，V2V)通信，车辆与基础设施(vehicle to infrastructure，V2I)通信、车辆与行人之间的通信(vehicle to pedestrian，V2P)或车辆与网络(vehicle to network，V2N)通信等。
本申请提供的技术方案还可以应用于未来的通信系统，如第六代(6th Generation，6G)移动通信系统等。本申请对此不作限定。
为方便理解，首先结合附图对适用于本申请实施例提供的方法的网络架构进行更详细地说明。
图1中的a)和b)分别示出了5G网络中的两种可能的架构：融合架构(参见图1中的a))和独立架构(参见图1中的b))。融合架构和独立架构的区别在于感知业务专用的SF部署的位置。
如图1中的a)所示，在融合架构中，SF可以部署在传统的5G核心网(5G core network，5GC)中，与其他网元使用serving based architecture，SBA接口相连接。有关SBA的更详细的说明可参看图2，此处暂且不作详述。SF连接于NEF，可通过NEF与5GC外部的服务器交互，比如接收外部服务器的感知请求消息。SF还可连接于UPF，基站等RAN设备可通过用户面将收到的感知数据发送给SF进行处理。
如图1中的b)所示，在独立架构中，SF部署可以在传统5GC之外，SF与其他网元不能使用SBA接口相连接，可能需要通过NEF(比如图中的NEF 1)的中转与其他5GC网元交互。一方面，SF也可连接于NEF(比如图中的NEF 2)，通过NEF与外部的服务器交互，或者，SF也可以直接与外部的服务器交互，而不通过NEF中转。另一方面，SF可连接于RAN设备，以与终端设备交互。
应理解，图1中的a)和b)分别示出的两种可能的架构仅以5GC的架构为例来示例，而不应对本申请构成任何限定。本申请提供的方法并不仅限于在图1所示出的两种架构中使用。
图2是本申请实施例提供的5G网络中的SBA的网络架构示意图。如图2所示，5G网络架构中可包括三部分，分别是终端、数据网络(data network，DN)和运营商网络。
下面对图1和图2中涉及的网元做简单说明。
终端，也可以称为用户设备(user equipment，UE)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端设备、无线通信设备、用户代理或用户装置。
终端是一种具有无线收发功能的设备。终端可经无线接入网中的接入网设备(或者称为接入设备)与一个或多个核心网(core network，CN)设备(或者称为核心设备)进行通信。终端设备可以部署在陆地上，包括室内或室外、手持或车载；也可以部署在水面上(如轮船等)；还可以部署在空中(例如飞机、气球和卫星上等)。
终端也可以是物联网(internet of things，IoT)系统中的终端，也可以称为IoT节点。IoT是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连，物物互连的智能化网络。连接可以通过宽带技术，也可以通过窄带(narrow band，NB)技术。IoT技术可以通过例如窄带技术，做到海量连接，深度覆盖，终端省电。
本申请实施例中，用于实现终端的功能的装置可以是终端，也可以是能够支持终端实现该功能的装置，例如芯片系统，该装置可以被安装在终端中或者和终端匹配使用。本申请实施例中，芯片系统可以由芯片构成，也可以包括芯片和其他分立器件。在本申请实施例中仅以用于实现终端的功能的装置为终端为例进行说明，不对本申请实施例的方案构成限定。
本申请中的终端可以硬件设备，也可以是在专用硬件上运行的软件功能、或通用硬件上运行的软件功能，还可以是虚拟化的设备，比如，通过通用硬件和实例化的虚拟化功能，或者，专用硬件和实例化的虚拟化功能来实现。其中，通用硬件可以为服务器，比如，云服务器。
其中，运营商网络可包括以下网元中的一个或多个：鉴权服务功能(authentication server function，AUSF)网元、网络开放功能(network explosure function，NEF)网元、策略控制功能(policy control function，PCF)网元、统一数据管理(unified data management，UDM)网元、网络存储功能(network repository function，NRF)网元、应用功能(application function，AF)网元、接入与移动性管理功能(access and mobility management function，AMF)网元、会话管理功能模块(session management function，SMF)网元、用户面功能(user plain function，UPF)网元、网络切片选择功能(network slice selection function，NSSF)网元、以及接入网(access network，AN)(如无线接入网(radio access network，RAN)网元)等。上述运营商网络中，除RAN网元之外的部分可以称为核心网络部分。下文中为方便说明，省去“网元”一词，比如AF网元简称AF，UDM网元简称UDM，SF网元简称SF，等等。
RAN是由多个RAN节点组成的网络，实现无线物理层功能、资源调度和无线资源管理、无线接入控制以及移动性管理功能。5G-RAN可通过用户面接口N3和用户面功能(user plane function，UPF)相连，用于传送终端设备的数据；5G-RAN通过控制面接口N2和接入和移动性管理功能(access and mobility management function，AMF)建立控制面信令连接，用于实现无线接入承载控制等功能。
RAN节点可以提供无线通信功能服务，将终端接入到无线网络中。RAN节点也可以称为RAN设备、或接入网设备等。
在一种可能的场景中，RAN节点可以是基站(base station)、演进型基站(evolved NodeB，eNodeB)、接入点(access point，AP)、发送接收点(transmission reception point，TRP)、下一代基站(next generation NodeB，gNB)、第六代(6th generation，6G)移动通信系统中的下一代基站或未来移动通信系统中的基站。RAN节点可以是宏基站、微基站或室内站、中继节点或施主节点、或者是云无线接入网络(cloud radio access network，CRAN)场景下的无线控制器。可选地，RAN节点还可以是服务器。
在另一种可能的场景中，由多个RAN节点协作协助终端实现无线接入，不同RAN节点分别实现基站的部分功能。例如，RAN节点可以是集中式单元(central unit，CU)，分布式单元(distributed unit，DU)，CU-控制面(control plane，CP)，CU-用户面(user plane，UP)，或者无线单元(radio unit，RU)等。CU和DU可以是单独设置，或者也可以包括在同一个网元中，例如基带单元(baseband unit，BBU)中。RU可以包括在射频设备或者射频单元中，例如包括在射频拉远单元(remote radio unit，RRU)、有源天线处理单元(active antenna unit，AAU)或远程射频头(remote radio head，RRH)中。
在不同系统中，CU(或CU-CP和CU-UP)、DU或RU也可以有不同的名称，但是本领域的技术人员可以理解其含义。例如，在开放式接入网(open RAN，O-RAN或ORAN)系统中，CU也可以称为开放式CU(O-CU)，DU也可以称为O-DU，CU-CP也可以称为O-CU-CP，CU-UP也可以称为O-CU-UP，RU也可以称为O-RU。为描述方便，本申请中以CU，CU-CP，CU-UP、DU和RU为例进行描述。本申请中的CU(或CU-CP、CU-UP)、DU和RU中的任一单元，可以是通过软件模块、硬件模块、或者软件模块与硬件模块结合来实现。
本申请实施例中，用于实现RAN节点功能的装置可以是RAN节点本身；也可以是能够支持RAN节点实现该功能的装置，例如芯片系统、硬件电路、软件模块、或硬件电路加软件模块。该装置可以被安装在RAN节点中或者和RAN节点匹配使用。在本申请实施例中仅以用于实现RAN节点的功能的装置为RAN节点为例进行说明，不对本申请实施例的方案构成限定。
本申请中的RAN节点可以是硬件设备，也可以是在专用硬件上运行的软件功能、或通用硬件上运行的软件功能，还可以是虚拟化的设备，比如，通过通用硬件和实例化的虚拟化功能，或者，专用硬件和实例化的虚拟化功能来实现。其中，通用硬件可以为服务器，比如，云服务器。
SF主要负责感知业务的相关处理，例如根据获取到的感知数据确定感知结果，如是否有人入侵，或者计算感知区域内感知周围反射物体的距离、方向、位置等。
AMF主要负责终端的认证、终端的移动性管理(mobility management，MM)、网络切片选择以及SMF选择等功能；作为N1和N2信令连接的锚点并为SMF提供N1/N2会话管理(session management，SM)消息的路由；维护和管理终端的状态信息。
SMF主要负责终端会话管理的所有控制面功能，包括UPF选择、互联网协议(internet protocol，IP)地址分配、会话的服务质量(quality of service，QoS)管理、(从PCF)获取PCC(policy and charging control)策略等。
UPF作为协议数据单元(protocol data unit，PDU)会话连接的锚定点，负责对终端的数据报文过滤、数据传输/转发、速率控制、生成计费信息等。
UDR主要用于存储用户数据，包括由UDM调用的签约数据、PCF调用的策略信息、用于能力开放的结构化数据、NEF调用的应用数据等。
UDM主要用于管控用户数据，例如签约信息的管理，包括从UDR获取签约信息并提供给其它网元(例如AMF)；为终端生成3GPP的认证凭证；登记维护当前为终端服务的网元(例如，AMF ID1所代表的AMF为终端当前的服务AMF，serving AMF))。
NEF用于连接核心网其它内部网元与核心网外部应用服务器(application server，AS)对应的应用功能(application function，AF)网元之间的交互，以将网络开放能力提供给AF，或者将AF提供的信息提供给核心网网元。
AUSF认证服务器功能，用于终端接入网络时对终端进行安全认证。
PCF主要进行服务质量(quality of service，QoS)策略和计费策略(charging)的策略控制等。为终端提供配置策略信息，为网络的控制面网元(例如AMF、SMF)提供管控终端的策略信息。
AF主要传递应用侧对网络侧的需求，可视为应用服务器或者应用服务器的代理。AF可以与核心网网元交互以提供一些服务，例如，与PCF交互以进行业务策略控制，与NEF交互以获取一些网络能力信息或提供应一些应用信息给网络，提供一些数据网络接入点信息给PCF以生成相应的数据业务的路由信息。
DN主要为用户提供业务服务。
各网元之间通过接口通信。例如，终端和AMF间的接口为N1接口，AN和AMF间的接口为N2接口，AN和UPF间的接口为N3接口，SMF和UPF间的接口为N4接口，UPF和DN间的接口为N6接口。部分网元之间可以基于服务化的接口进行通信，其中，图1中的Nnssf、Nnef、Nnrf、Npcf、Nudm、Naf、Nusf、Namf、Npcf、Nsf就是基于业务的服务化的接口。其中，接口Nsf仅为一种可能的命名，本申请并不限定与SF对应的服务化接口的名称。
上文关于核心网中的各个网元以及各个网元之间的接口仅为示例性说明，不应对本申请构成任何限定。此外，图中所示的各个网元可以理解为核心网中用于实现不同功能的网元，例如可以按需组合成网络切片。这些核心网网元可以是各自独立的设备，也可以集成于同一设备中实现不同的功能，本申请对于上述网元的具体形态不作限定。
可以理解，在未来通信系统中应用的网元可以是上述各网元，或者，也可以是具备相同或相似功能的其它名称的网元，本申请对此不作限定。
本申请实施例中，用于实现核心网各功能的装置可以是各功能对应的核心网网元；也可以是能够支持核心网网元实现各自功能的装置，例如芯片系统、硬件电路、软件模块、或硬件电路加软件模块。该装置可以被安装在核心网网元中或者和核心网网元匹配使用。在本申请实施例中仅以用于实现核心网功能的装置为核心网网元为例进行说明，不对本申请实施例的方案构成限定。
本申请中的核心网网元可以是硬件设备，也可以是在专用硬件上运行的软件功能、或通用硬件上运行的软件功能，还可以是虚拟化的设备，比如，通过通用硬件和实例化的虚拟化功能，或者，专用硬件和实例化的虚拟化功能来实现。其中，通用硬件可以为服务器，比如，云服务器。
目前，RAN中的一些基站或终端因拥有电磁波所带来的感知能力，可用作感知节点。感知的实现与雷达的原理相似。即，发射机(也即，感知节点)发射电磁波，电磁波经需要感知的物体反射后由接收机获取，接收机(也即，感知节点)可进一步根据获取的反射信号(可以称为感知原始数据)处理得到感知数据，该感知数据可以用来获取感知结果。
例如，当基站被用作感知节点时，具有如表A和图3中的功能。其中，表A为测速雷达、监控雷达、成像雷达的感知能力的举例。
表A
图3是基站执行感知操作的示意图。图3是通信感知一体化(integrated sensing and communication，ISAC)的一个示例。图3所示的基站可以复用通信系统的电磁波信号来进行感知。如图所示，基站进行通信的资源和进行感知的资源可以是时分复用的(如图3所示)、也可以是空分复用的。基站可以利用电磁波信号来进行感知探测，同时也可以接收到达障碍物(也即探测到的目标物)后被发射回来的信号(可简称反射信号，或者称回波信号)，根据回波信号来获取感知数据。如图3所示，基站可以对待发送的信号进行串并转换、相移键控、快速傅里叶逆变换(inverse fast Fourier transform，IFFT)、并串转换、数模转换等，基站也可以对接收到的回波信号进行模数转换、并串转换、快速傅里叶变换(fast Fourier transform)、串并转换、解调等。待发送的信号还可以被发送至雷达处理器，以便于雷达处理器根据待发送的信号和接收到的回波信号(可以理解，此处的回波信号是经过了上述处理后的回波信号)来获取感知数据。应理解，图3所示的基站对待发送的信号和接收到的回波信号所执行的处理仅为示例，不应对本申请构成任何限定。
通信系统中的感知节点可以对指定区域、指定的物体或事件进行感知识别，在自动驾驶、安全监管、家庭健康、气象监测等多个方面满足感知需求。具体示例如下：
一、自动驾驶
在V2X和无人机(unmanned aerial vehicle，VAU)场景下，例如，由于车辆或无人机的感知距离较短或非视距(not line of sight，NLOS)径无法感知，可以基于感知数据生成动态地图；又例如，在车辆或无人机行驶过程中，可能存在行人或非机动车等突然出现、或行人或非机动车等处于视野盲区等交通危险事件，可以基于感知数据识别危险事件并通知车辆或无人机执行紧急操作；再例如，在车辆或无人机自动驾驶辅助，基于感知数据生成定制化高精度动态地图辅助车辆或无人机进行自动驾驶。
二、安全监管
在V2X和无人机场景下，可以基于感知数据识别车辆或无人机违规行驶，如车辆占用应急车道、无人机离开航路行驶等，并可以执行实时告警。
在周界安防场景下，可以基于感知数据，检测到异物入侵铁路轨道或无人机入侵禁飞区(比如机场)等情况，并可以跟踪违规物体，并执行实时应急处理。
三、家庭健康
例如，可以基于感知数据识别异常姿势，从而可以识别到跌倒等情况，并可及时告警；又例如，可以感知数据获得人体呼吸或心跳等生理参数，从而可以识别异常，并及时告警。
四、气象监测
可以对环境、气候、天气变化等进行感知预测。
图4是影响感知精度和分辨率的参数示意图。图4以车联网场景为例，示出了影响感知的KPI中感知定位精度(包括垂直和水平)、感知速度精度(包括垂直和水平)、感知分辨率(包括区域和速度)的几个参数。
1.距离分辨率α：在距离上区分邻近目标的能力，通常以最小可分辨的距离间隔来度量，用于识别不同的车辆。
2.速度分辨率β：在径向速度上区分目标的能力。
3.测角精度θ：雷达在角度上区分邻近目标的能力，通常以最小可分辨的角度来度量。
4.水平视场角(field of view，FOV)：图4所示的FOV为120°，在该120°的FOV下，双向车道路宽30米情况下的双向盲区范围小于18m，盲区面积比例<1％。
为方便理解本申请的实施例，首先做出如下几点说明：
第一，本申请中，指示包括显式指示(也称为直接指示)和隐式指示(也称为间接指示)。其中，显示指示信息A，是指包括该信息A；隐式指示信息A，是指通过信息A和信息B的对应关系以及直接指示信息B，来指示信息A，信息A和信息B的对应关系可以是预定义的，预存储的，预烧制的，或者，预先配置的；或者，也可以是指通过信息B和预设的规则，来指示信息A。
第二，本申请中，信息C用于信息D的确定，既包括信息D仅基于信息C来确定，也包括基于信息C和其他信息来确定。此外，信息C用于信息D的确定，还可以间接确定的情况，比如，信息D基于信息E确定，而信息E基于信息C确定这种情况。
第三，本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系，但并不排除表示前后关联对象是一种“和”的关系的情况，具体表示的含义可以结合上下文进行理解。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c；a和b；a和c；b和c；或a和b和c。其中a，b，c可以是单个，也可以是多个。
第四，本申请中，“第一”、“第二”等前缀字样的使用仅仅为了便于对归属于同一个名称类别下的不同事物进行区分描述，不对事物的次序、大小或者数量进行约束。例如，“第一通信装置”和“第二通信装置”仅仅为不同的通信装置，二者没有大小关系或优先级高低关系。
第五，本申请中的“发送”和“接收”，表示信号传递的走向。例如，“向终端发送信息”可以理解为该信息的目的端是终端，可以包括通过空口直接发送，也包括其他单元或模块通过空口间接发送。“接收来自终端的信息”可以理解为该信息的源端是终端，可以包括通过空口直接从终端接收，也可以包括通过空口从其他单元或模块间接地从终端接收。“发送”也可以理解为芯片接口的“输出”，“接收”也可以理解为芯片接口的“输入”。
第六，在本申请实施例中，“当…时”、“若”以及“如果”均指在某种客观情况下装置会做出相应的处理，并非是限定时间，且也不要求装置实现时一定要有判断的动作，也不意味着存在其它限定。
第七，本申请中，“示例”、“示例性地”、“例如”或“比如”等词用于表示作例子、例证或说明。本申请中被描述为“示例”、“示例性地”、“例如”或“比如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例”、“示例性地”、“例如”或“比如”等词旨在以具体方式呈现相关概念。
第八，本申请中，引入了多种消息名称，比如感知请求、感知授权请求、感知授权回复、业务要求请求、业务要求回复、感知通知请求，等等，这些消息仅为便于区分示例，不应对本申请构成任何限定，本申请并不限定各信令的名称。
第九，本申请中各表所示的对应关系仅为示例，不应对本申请构成任何限定。各表中的内容仅仅是举例，可以配置为其他内容，本申请并不限定。在配置这些对应关系时，并不一定要求必须配置各表中示意出的所有对应关系。例如，某些行示出的对应关系也可以不配置。又例如，某些列也可以替换为其他的形式。再例如，可以基于本文所示出的表格做适当的变形调整，例如，拆分，合并等等。
另外，表格仅为对应关系的一种可能的形式，在具体实现时，也可以采用其他的数据结构，例如可以采用数组、队列、容器、栈、线性表、指针、链表、树、图、结构体、类、堆、散列表或哈希表等。
在目前的感知流程中，感知应用的AF或AS可以向NEF发送感知请求消息，以请求对特定的终端进行感知，感知应用的AF、AS或承载感知应用的终端也可直接向通信网络中负责感知功能的网元发送感知请求消息。响应于该感知请求消息，通信网络中负责感知功能的网元(比如SF或感知服务端)可以发起对特定的终端的感知流程。
在针对特定业务类型或特定终端的感知请求消息中，AF、AS或终端通常会指示业务要求，该业务要求可用于描述感知请求消息的发送方对于感知结果的需求，比如精确度、分辨率、时延、或刷新率等等。而不同的终端可能具有不同的安全需求，有些终端可能不希望将自身的信息(比如位置、或移动速度等)暴露给外部，还有些终端可能不希望将自身的信息以较高的精度暴露给外部，等等。而发起感知请求的AF、AS或终端并不一定预先知晓请求被感知的各终端的安全需求。而考虑到处理简单等原因，SF或感知服务端可能会直接根据感知请求消息中的业务要求来发起对终端的感知，而不能灵活地根据终端不同的安全需求来适应性地对业务要求做出调整，从而无法满足不同终端不同的安全需求。不难看出，目前针对特定终端的感知流程，暂无相关安全的流程。
本申请提供一种感知方法，网络中负责感知功能的网元(比如SF或感知服务端)在接收到针对该终端的感知请求消息时，可以获取对该终端进行感知所采用的业务要求(即下文的目标业务要求)，该业务要求与该终端的感知权限相关。从而使得对于终端发起的感知流程是与终端的感知权限相适应的，而不是盲目地直接根据AF网元或AS等请求的业务要求来确定对终端进行感知的KPI。或者说，本申请可以以终端为粒度来获取目标业务要求。具体地，不同终端的目标业务要求可以根据各自对应的感知权限来确定。因此，考虑到不同终端的安全需求，灵活地根据不同终端的感知权限，获取不同的目标业务要求，进而基于不同的KPI对不同的终端发起感知流程，而不是盲目地根据AF网元或AS请求的业务要求，采用相同的KPI对所有被请求感知的终端进行感知。
下面将结合附图，详细说明本申请提供的方法。
需要说明的是，下文结合多个附图所示的实施例中，以UDM作为数据管理功能网元的一例、AF和AS作为第一通信装置的两个示例，SF和感知服务端分别作为第二通信装置的两个示例，来描述本申请提供的方法。这些设备仅为一种示例，不应对本申请构成任何限定。AF、AS、UDM、SF、感知服务端等也可以替换为其他可实现相同或相似功能的网元，本申请对此不作限定。
图5是本申请提供的感知方法的示意性流程图。图5从设备交互的角度示出了该方法。如图5所示，该方法500包括步骤501至513。图5中的SF也可以替换为SF中的组件，如芯片、芯片系统或处理器等，或者还可以替换为能够实现该SF的部分或全部功能的逻辑模块或软件；图5中的UDM也可以替换为UDM中的组件，如芯片、芯片系统或处理器等，或者还可以替换为能够实现该UDM的部分或全部功能的逻辑模块或软件；图5中的AF也可以替换为AF中的组件，如芯片、芯片系统或处理器等，或者还可以替换为能够实现该AF的部分或全部功能的逻辑模块或软件。
下面详细说明方法500中的各个步骤。
在步骤501中，AF向NEF发送感知请求，该感知请求用于请求对终端进行感知。
示例性地，该感知请求可携带请求被感知的终端的外部标识以及如下一项或多项：AF的标识、请求的业务类型、请求的业务要求、或请求感知的时间信息。
其中，终端的外部标识可用于标识该终端。由于AF并不知晓终端在该通信系统中的标识，因此这里以外部标识来命名，以便与终端在通信系统中的标识区分。
AF的标识用于标识该AF，可以理解，当AF为AS时，该AF的标识也可替换为AS的标识。
请求的业务类型可以是预定义的至少一种业务类型中的一种或多种。该至少一种业务类型例如可以包括但不限于，无人机入侵检测、自动驾驶、安全监管、家庭健康、或气象监测等，本申请包含但不限于此。
请求的业务要求可用于描述对请求的感知结果的需求。例如，请求的业务要求包括如下一项或多项：感知位置精度、感知速度精度、感知分辨率、或感知所需的持续时间。业务要求可以用来确定该感知请求所请求的感知结果对应的KPI。
示例性地，第三代合作伙伴计划(3rd generation partnership project，3GPP)技术规范(technical specification，TS)22.173中对于感知KPI定义了如下指标：置信区间、感知定位精度(包括垂直和水平)、感知速度精度(包括垂直和水平)、感知分辨率(包括区域和速度)、最大感知服务时延和刷新率等。这些参数可用于描述需要以怎样的精确度获取到感知数据。
当然，这些指标仅为感知的KPI的一个示例，本申请并不限定感知的KPI具体包含的指标。
请求感知的时间信息可用于请求感知的时间，请求感知的时间具体可以是指，请求对该终端进行感知的时间，或者请求发起对该终端的感知流程的时间。
在前文结合图1的a)和b)所示的架构可知，SF可能部署于融合架构，也可能部署于独立架构。AF可通过NEF向SF发送该感知请求，因此，相应地，在步骤501中，NEF接收来自AF的感知请求。
在步骤502中，NEF从UDM获取对感知请求的授权。
示例性地，步骤502可以包括如下步骤5021至5023：
步骤5021，NEF向UDM发送感知授权请求，该感知授权请求用于请求UDM授权该感知请求，或用于请求UDM对该感知请求进行授权检查。
步骤5022，UDM根据终端签约的感知权限，确定该终端允许或不允许被感知。
步骤5023，UDM向NEF发送感知授权回复，该感知授权回复用于指示授权或拒绝授权该感知请求。
该感知授权请求例如可以携带上述感知请求中的信息，例如，终端的外部标识以及如下一项或多项：AF的标识、请求的业务类型、请求的业务要求、或请求感知的时间信息。一种可能的设计中，该感知授权请求可以为上述感知请求。另一种可能的设计中，该感知授权请求是通过对上述感知请求进行处理得到的。本申请对此不作限定。
UDM可以根据终端签约的感知权限，确定终端允许或不允许被感知(即终端是否允许被感知)，并通过感知授权回复来指示授权或拒绝授权该感知请求。UDM可以在确定终端允许被感知的情况下，通过感知授权回复指示授权该感知请求，如图中的5023a所示；在确定终端不允许被感知的情况下，通过感知授权回复指示拒绝授权该感知请求，如图中的5023b所示。可以理解，5023a和5023b可以视为步骤5023的两种可能的情况，可择一执行。
可以理解，该感知授权回复指示授权感知请求时，该感知授权回复也可以称授权消息；该感知授权回复指示拒绝授权该感知请求时，该感知授权回复也可以称拒绝授权消息。
其中，终端签约的感知权限为该终端与网络运营商签约的感知权限，也可以称配置的感知权限，或默认的感知权限，或网络侧存储的感知权限。例如，终端可通过与运营商签约来明确自身是否允许被感知。终端签约的感知权限可以是预先配置在该UDM中的，比如，可以由人工存入该UDM中，或者AF预先向UDM发送的。本申请对此不作限定。
示例性地，该终端签约的感知权限可以包括如下多种权限中的一种：允许被感知，不允许被感知，允许被感知、需要通知终端但无需终端回复，需要通知终端、在终端回复同意或未回复的情况下允许被感知，或者需要通知终端、仅在终端回复同意的情况下允许被感知。其中，“需要通知终端、在终端回复同意或未回复的情况下允许被感知”具体为：需要通知终端，在终端回复同意或终端未回复的情况下允许被感知、在终端回复不同意的情况下不允许被感知；“需要通知终端、仅在终端回复同意的情况下允许被感知”具体为：需要通知终端、在终端回复同意的情况下允许被感知、在终端回复不同意或终端未回复的情况下不允许被感知。
表一示出了几种可能的权限。
表一
对于每个终端来说，其签约的感知权限为表一所示出的多种权限中的一种。可替换地，该终端签约的感知权限可以包括如下多种权限中的一种：允许被感知，不允许被感知，允许被感知、需要通知终端但无需终端回复，需要通知终端、在终端回复不同意或未回复的情况下不允许被感知，或者需要通知终端、仅在终端回复不同意的情况下不允许被感知。其中，“需要通知终端、在终端回复不同意或未回复的情况下不允许被感知”具体为：需要通知终端，在终端回复不同意或终端未回复的情况下不允许被感知；“需要通知终端、仅在终端回复不同意的情况下不允许被感知”具体为：需要通知终端，在终端回复同意或未回复的情况下允许被感知，在终端回复不同意的情况下不允许被感知。每个终端签约的感知权限也可以多种权限中的一种。
每个终端签约的感知权限可预配置在UDM中，例如通过终端的标识与该终端签约的感知权限所包括的权限的索引来指示。比如，终端1签约的感知权限为允许被感知，终端2签约的感知权限为不允许被感知，终端3的感知权限为允许被感知、需要通知终端但无需终端回复，终端4签约的感知权限为需要通知终端、在终端回复同意或未回复的情况下允许被感知，终端5签约的感知权限为需要通知终端、仅在终端回复同意的情况下允许被感知。则该五个终端签约的感知权限可如表二所示。
表二
当然，表二中签约的感知权限一列也可替换为各终端分别签约的感知权限，而不通过索引来指示，表二仅为示例，不应对本申请构成任何限定。
步骤5022中，如果终端签约的感知权限为允许被感知，或为允许被感知、需要通知终端但无需终端回复，则UDM可直接确定该终端允许被感知，可以对该感知请求授权。如果终端签约的感知权限为不允许被感知，则UDM可直接确定该终端不允许被感知，可以拒绝对该感知请求授权。如果终端签约的感知权限为需要通知终端、在终端回复同意或未回复的情况下允许被感知，或为需要通知终端、在终端未回复的情况下允许被感知，或为需要通知终端、在终端未回复的情况下不允许被感知，或为需要通知终端、仅在终端回复同意的情况下允许被感知，则UDM暂时无法确定该终端是否允许被感知，还需要结合终端的回复来确定，此时UDM可以对该感知请求授权，以便执行后续的流程。需注意，UDM对感知请求授权，并不代表该感知请求一定会被执行，而是为了方便执行后续的流程，暂时对该感知请求授权，以便将终端是否允许被感知的判别交由其他网元来执行，比如在本实施例中交由SF来执行，SF可以在接收到感知请求后，确定终端是否允许被感知，并在确定终端允许被感知的情况下获取目标业务要求，在确定终端不允许被感知的情况下拒绝该感知请求。换句话说，向UDM请求获取对感知请求的授权，可以视为UDM对感知请求进行初筛，而并不一定能够将针对不允许被感知的终端发起的感知请求全部过滤。下文中为了简洁，省略对相同或相似情况的说明。
进一步地，终端签约的感知权限可以与至少一个区域对应，和/或，与至少一个时段对应。换句话说，终端签约的感知权限包括与至少一个区域对应的至少一种感知权限，和/或，终端签约的感知权限包括与至少一个时段对应的至少一种感知权限。或者说，终端签约的感知权限可以因位置和/或时间的不同而不同。比如，终端签约的感知权限在区域1与在区域2不同，或者，终端签约的感知权限在时段A与在时段B不同，等等，不再列举。示例性地，位置可以包括以下一项或多项：坐标信息、地理区域标识、地址信息、追踪区标识(tracking area identifier，TAI)、或小区标识(cell identifier，cell ID)。
示例性地，表三示出了不同的权限与不同的位置、不同的时间的对应关系。
表三
对于每个终端来说，其签约的感知权限包括表三所示例的多组对应关系中的一组或多组。也就是说，一个终端在的感知权限可以对应特定的区域和/或特定时段，进一步地，一个终端在不同的区域可以对应相同的感知权限，也可以对应不同的感知权限；在不同的时段可以对应相同的感知权限，也可以对应不同的感知权限。
应理解，表三仅为一种示例，也可以拆分为两个表格，即用于指示不同的权限与不同的时段的对应关系的表格和用于指示不同的权限与不同的区域的对应关系的表格。
如果终端签约的感知权限包括与至少一个区域对应的至少一种感知权限，由于UDM不能直接与终端交互，UDM可能暂时无法获取到终端的位置，因此暂时无法确定该终端签约的感知权限，也就可能无法确定该终端是否允许被感知，因此可以对该感知请求授权，以便执行后续的流程。
如果终端签约的感知权限包括与至少一个时段对应的至少一种感知权限，则UDM可以根据接收到该感知请求的时间所属的时段，来确定与之对应的感知权限，进而确定终端是否允许被感知。当然，UDM也可能需要结合终端的回复来确定，因此，在感知请求的时间所属的时段在上述至少一个时段的范围内，且需要进一步结合终端的回复来确定该终端允许被感知的情况下，可以对该感知请求授权，以便执行后续的流程。
综上可以看到，UDM可以根据终端签约的感知权限，对感知请求进行初筛，使得针对不允许被感知的终端的感知请求直接被拒绝，而不必再发送给SF。从而可以减少后续给SF发送感知请求带来的信令开销，以及SF确定该终端是否允许被感知，以及确定目标业务要求带来的处理量。
可选地，该UDM可以在确定对感知请求授权的情况下，根据该终端的外部标识确定该终端在通信系统中的标识，比如该终端的用户永久标识符(subscription permanent identifier，SUPI)，并将该终端的SUPI携带在感知授权回复中。换言之，上述感知授权回复中携带终端的SUPI。
可选地，该UDM可以在确定对感知请求授权的情况下，将该终端签约的感知权限，和/或用于确定目标业务要求的映射关系携带在感知授权回复中。换言之，上述感知授权回复中携带该终端签约的感知权限和/或用于确定目标业务要求的映射关系。其中，用于确定目标业务要求的映射关系可以包括包括如下一项或多项：至少一种业务要求与至少一个时段的对应关系，至少一种业务要求与至少一个区域的对应关系，或至少一种业务要求与时段和区域的至少一种组合的对应关系。由于在后文的步骤505中结合第一映射关系、第二映射关系和第三映射关系对该映射关系做了详细说明，此处暂且不作详述。可选地，该UDM可以在确定拒绝对该感知请求授权的情况下，将拒绝的原因携带在该感知授权回复中。换言之，上述感知授权回复中携带拒绝原因。例如，拒绝感知请求的原因是，终端不允许被感知。
综上，该感知授权回复(或者说，授权消息)指示授权感知请求，且携带如下一项或多项：终端的SUPI、终端签约的感知权限或用于确定目标业务要求的映射关系，如图中的5023a所示，或者，该感知授权回复(或者说，拒绝授权消息)指示拒绝授权感知请求，且指示拒绝的原因，如图中的5023b所示。
NEF可以根据接收到的感知授权回复，来确定是否继续向SF发送感知请求。如果该感知授权回复指示授权该感知请求，则可执行步骤503，NEF向SF发送感知请求；如果该感知授权回复指示拒绝授权该感知请求，则可执行步骤504，NEF向AF发送拒绝消息。
需要说明的是，步骤502并不一定是必须要执行的，比如，在如图1的b)所示的独立架构中，NEF可直接将该感知请求转发给SF，而不必请求获得UDM的授权。即便是在如图1的a)所示的融合架构中，NEF也可以直接将感知请求转发给SF，本申请对此不作限定。
在步骤503中，NEF向SF发送感知请求。
一种可能的实现方式是，NEF可以将接收到的感知请求直接转发给SF，因此，SF接收到的感知请求中也携带请求感知的终端的外部标识以及如下一项或多项：AF的标识、请求的业务类型、请求的业务要求、或请求感知的时间信息。
另一种可能的实现方式是，NEF可以在向SF发送该感知请求之前，将接收到的感知请求先发给UDM，经过UDM的授权后再转发给SF。
如果NEF在步骤503之前，已经通过步骤502获得UDM的授权，则该步骤503可以是在接收到来自UDM的授权消息的情况下执行的。为方便理解，本文中假设UDM确定终端允许被感知，并向NEF发送授权消息。
如前所述，感知授权回复可以携带终端的SUPI，NEF可以根据该感知授权回复中携带终端的SUPI，将从AF接收到的感知请求中的终端的外部标识替换为终端的SUPI，并将替换成终端的SUPI的感知请求发送给SF。感知授权回复中还可以携带终端签约的感知权限和/或用于确定目标业务要求的映射关系，NEF也可以将该感知授权回复中携带的感知权限和/或用于确定目标业务要求的映射关系携带在感知请求中发送给SF。此情况下，也可以称步骤501中AF发送的感知请求为第一感知请求，步骤502中NEF发送的感知请求为第二感知请求。可以理解，第一感知请求和第二感知请求都可用于请求对终端进行感知，不同之处在于，第一感知请求所携带的终端的标识为该终端的外部标识，第二感知请求所携带的终端的标识为该终端的SUPI，且第二感知请求中还可以携带感知权限和/或用于确定目标业务要求的映射关系。也就是说，第二感知请求中携带终端的SUPI，以及如下一项或多项：AF的标识、请求的业务类型、请求的业务要求、该终端签约的感知权限或用于确定目标业务要求的映射关系。
综上可知，SF在步骤502中接收到的感知请求可能是第一感知请求，也可能是第二感知请求。下文中为方便说明，将第一感知请求和第二感知请求统称为感知请求。
当然，UDM也可以不将终端的SUPI携带在授权消息中，此时，NEF向SF发送的感知请求可以是从AF接收到的感知请求，本申请对此不作限定。
此外，如果在步骤503之前没有从UDM获取对感知请求的授权(比如，在如图1的b)所示的独立架构中，NEF可直接将该感知请求转发给SF，而不必请求获得UDM的授权，或NEF直接将感知请求转发给SF)，NEF向SF发送的感知请求也可以是从AF接收到的感知请求。
在步骤504中，NEF向AF发送拒绝消息，该拒绝消息用于拒绝感知请求。
前已述及，如果NEF接收到来自UDM的感知授权回复指示拒绝授权感知请求，则可向AF发送拒绝消息，以拒绝该感知请求。可选地，该拒绝消息可指示拒绝感知请求的原因。该拒绝的原因可以是从来自UDM的感知授权回复中获得的，也可以是NEF自行确定的，本申请对此不作限定。
一种可能的实现方式是，NEF可以将从UDM接收到的感知授权回复直接转发给AF，即，上述感知授权回复和拒绝消息可以为同一消息。另一种可能的实现方式是，该NEF可以基于从UDM接收到的感知授权回复生成拒绝消息，即，上述感知授权回复和拒绝消息可以为不同的消息。在步骤505中，SF确定终端是否允许被感知。
在本申请实施例中，目标业务要求与终端的感知权限相关，包括：目标业务要求是在确定该终端允许被感知的情况下获取的，和/或，该目标业务要求是根据终端的感知权限确定的。本实施例主要提供了在确定终端允许被感知的情况下获取目标业务要求的处理流程。
SF在接收到该感知请求后，可以先确定该终端允许或不允许被感知(即终端是否允许被感知)，进而在终端允许被感知的情况下获取目标业务要求。
终端是允许或不允许被感知可以根据终端签约的感知权限和/或终端的感知通知反馈来确定。关于终端签约的感知权限在上文步骤502中已经做了详细说明，可参看上文相关内容，不再赘述。
一种可能的实现方式是，SF根据终端签约的感知权限确定终端允许或不允许被感知。如果终端是否允许被感知不需要结合终端的回复(比如本文所述的感知通知反馈)来确定，比如，该终端签约的感知权限为不允许被感知，或为允许被感知，或为允许被感知、需要通知终端但无需终端回复，则可直接确定该终端是否允许被感知。该终端签约的感知权限可以是从UDM获取的，也可以是预先配置在SF中的，本申请对此不作限定。
可以理解，如果上文的步骤502已执行，则UDM可以根据终端签约的感知权限确定终端是否允许被感知，步骤505可不必执行。
另外，如果终端签约的感知权限包括与至少一个区域对应的至少一种感知权限，则SF可获取终端的位置(例如通过发起对终端的定位流程)，进而根据终端的位置所属的区域确定对应的感知权限，进而确定该终端是否允许被感知。
示例性地，SF可触发RAN节点发起对终端的定位流程。RAN节点可以发送参考信号来获取终端对该参考信号的测量数据，比如相对到达时间(relative time of arrival，RTOA)、参考信号的到达角(angle of arrival，AOA)、参考信号接收功率(reference signal receiving power，RSRP)等等。RAN节点可以根据该测量数据来确定终端的位置，并上报给SF。关于对终端的定位流程的具体实现过程可参看已有技术，本文不作详述。
另一种可能的实现方式是，SF可以根据终端的感知通知反馈来确定终端是否允许被感知。
该感知通知反馈可指示终端回复同意被感知，或终端回复不同意被感知，或终端未回复。SF可以在感知通知反馈指示终端回复同意被感知的情况下，确定终端允许被感知；在终端回复不同意被感知的情况下，确定终端不允许被感知，而在终端未回复的情况下，SF可以结合预设规则(比如，该终端签约的感知权限)来确定终端是否允许被感知。
又一种可能的实现方式是，SF根据终端签约的感知权限和终端的感知通知反馈，确定终端是否允许被感知。
例如，该终端签约的感知权限为需要通知终端、在终端回复同意或未回复的情况下允许被感知，而终端的感知通知反馈指示终端未回复，则可确定该终端允许被感知。
又例如，该终端签约的感知权限为需要通知终端、仅在终端回复同意的情况下允许被感知，而终端的感知通知反馈指示终端未回复，则可确定该终端不允许被感知。
在有些情况下，虽然该终端签约的感知权限为允许被感知、需要通知终端无需终端回复，但终端回复不同意被感知，此时可以以终端的感知通知反馈为主，确定该终端不允许被感知。换句话说，终端的感知通知反馈的优先级高于终端签约的感知权限的优先级。
关于该终端签约的感知权限可参看上文的相关说明，不再赘述。
可选地，该方法还包括步骤506：SF获得终端的感知通知反馈。
SF可以通过发送感知通知请求，来获得终端的感知通知反馈。其中，该感知通知请求用于请求终端回复是否同意被感知。可选地，步骤506具体包括：SF发送该感知通知请求，SF从该感知通知请求的响应消息获得终端的感知通知反馈。
图中从设备交互的角度示出了步骤506的一种可能的实现方式。示例性地，步骤506具体包括如下步骤5061至5064：
步骤5061，SF向AMF发送感知通知请求。
步骤5062，AMF向终端转发该感知通知请求，以获取终端的回复。
步骤5063，AMF向SF发送感知通知请求的响应消息，该感知通知请求的响应消息指示终端回复同意被感知、终端回复不同意被感知或终端未回复。
步骤5064，SF根据该感知通知请求的响应消息获得感知通知反馈。
示例性地，该感知通知请求中携带感知请求，或者，该感知通知请求中携带终端的SUPI，以及如下一项或多项：AF的ID、请求的业务要求或请求的业务类型。进一步地，该感知通知请求还用于指示AMF回复感知通知反馈。
该感知通知请求的响应消息可以是针对该感知通知请求的响应消息，可用于指示该感知通知反馈。一种可能的设计是，该感知通知请求的响应消息中携带该感知通知反馈。
需要说明的是，SF和终端之间可以通过AMF、RAN节点等网元的中转来通信，因此，感知通知请求可以是通过AMF和RAN节点转发给终端的，AMF也可以根据终端回复的内容或者未回复的状态，通过该感知通知请求的响应消息来指示终端的感知通知反馈，SF可以根据该感知通知反馈确定终端是否允许被感知。
还需要说明的是，终端的感知通知反馈用于指示终端的回复内容或是否回复的状态，而并不表示终端一定做出反馈。该终端的感知通知反馈可以理解成是AMF根据感知通知请求，结合终端是否回复或回复的内容而得到的。
综上，终端允许被感知可能存在如下多种可能的情况：
1)该终端签约的感知权限为允许被感知；
2)该终端签约的感知权限为允许被感知，需要通知终端但无需终端回复，终端未回复；
3)需要通知终端、在终端回复同意或未回复的情况下允许被感知，且终端的感知通知反馈指示终端回复同意被感知或终端的感知通知反馈指示终端未回复；
4)需要通知终端、仅在终端回复同意的情况下允许被感知，且终端的感知通知反馈指示终端回复同意被感知；
5)该终端无签约的感知权限，但终端的感知通知反馈指示终端同意被反馈。
与之相对，终端不允许被感知可能存在如下多种可能的情况：
1)该终端签约的感知权限为不允许被感知；
2)需要通知终端、在终端回复同意或未回复的情况下允许被感知，且终端的感知通知反馈指示终端回复不同意被感知；
3)需要通知终端、仅在终端回复同意的情况下允许被感知，且终端的感知通知反馈指示终端回复不同意被感知或终端的感知通知反馈指示终端未回复；
4)该终端无签约的感知权限，但终端的感知通知反馈指示终端回复不同意被感知；
5)该终端签约的感知权限为允许被感知，需要通知终端但无需终端回复，但终端回复不同意被感知。
上文结合多种可能的权限和多个例子示出了确定终端是否允许被感知的多种可能的实现方式。这些例子仅为便于理解而示出，不应对本申请构成任何限定。
此外，终端签约的感知权限可以是预存在SF中的，也可以是SF从UDM获取到的。
可选地，该方法还包括：步骤507，SF从UDM获取终端签约的感知权限。
SF可以根据接收到的感知请求，确定该感知请求是针对某一终端的，则可向UDM请求获取该终端签约的感知权限。
如前所述，该感知请求还携带AF的标识。SF可以根据该AF的标识确定该感知请求是否来自权威机构或监管机构。示例性地，SF中可以预存有AF列表，该AF列表包含预定义的机构对应的AF的标识。该预定义的机构可以这样理解：来自该预定义的机构的感知请求必须要执行，而不必确认终端是否允许被感知，换言之，步骤508至510可以跳过不执行，直接执行步骤511至512。该预定义的机构例如可以是权威机构或监管机构。SF根据该机构列表以及感知请求中携带的AF的标识，确定该感知请求是否来自预定义的机构。
此外，如果SF在从NEF接收到的感知请求中获取到的终端的标识为外部标识，而非SUPI，SF也可以在步骤507中获取该终端的SUPI。
如果SF在步骤505中确定终端允许被感知，则可继续执行步骤508至步骤513中的部分步骤；如果SF在步骤505中确定终端不允许被感知，则可执行步骤513，SF向AF发送拒绝消息。
在步骤508中，SF获取目标业务要求。
步骤508的一种可能的实现方式如步骤508a所示：SF确定目标业务要求。
在一种可能的设计中，SF中可以预存业务要求，该业务要求可以称为默认的(default)业务要求。SF可以在终端允许被感知的情况下，直接确定出目标业务要求。
在另一种可能的设计中，上述感知请求中可以携带请求的业务要求，SF可以在终端允许被感知的情况下将该请求的业务要求确定为目标业务要求。或者说，SF也可以将默认的业务要求定义为请求的业务要求，而不对默认的业务要求进行预配置。
在又一种可能的设计中，该目标业务要求可以根据该感知请求的时间信息和/或终端的位置来确定。也就是说，SF可以确定出与该感知请求的时间信息和/或终端的位置相对应的目标业务要求。
一个示例，该目标业务要求可以根据该感知请求的时间信息来确定。
该感知请求的时间信息可用于指示如下一项或多项：AF发起感知请求的时间、SF接收到感知请求的时间、或该感知请求中携带的请求感知的时间。
SF可以根据该时间信息确定所处的时段，进而确定目标业务要求。
例如，该时间信息指示的时间为夜间休息时间，比如21:00-7:00，由于用户处于休息状态，不希望隐私被暴露，因此可以将目标业务要求确定为感知精度较低的业务要求。
另一个示例，该目标业务要求可以根据该终端的位置来确定。
该终端的位置可以由SF获取，根据该终端的位置，可以确定与该位置相对应的目标业务要求。
例如，该终端的位置为用户的家中，用户可能并不希望隐私被暴露，因此可以将目标业务要求确定为感知精度较低的业务要求。
再一个示例，该目标业务要求可以根据感知请求的时间信息和终端的位置来确定。
例如，该时间信息指示的时间处于早高峰或晚高峰时段，比如7:00-9:00，或17:00-19:00，终端的位置为公路上，由于在早、晚高峰时段，公路上有较多的终端，较高感知精度的感知可能会涉及一些隐私或者敏感信息的外泄，因此可以将目标业务要求确定为感知精度较低的业务要求。
综上可以看到，结合感知请求的时间信息和/或终端的位置，可以有效地避免用户隐私被暴露，减少敏感信息的外泄，既能满足终端的安全需求，又可以有效且灵活地提供网络开放能力。
在一种可能的实现方式中，与感知请求的时间信息和/或终端的位置对应的目标业务要求可以通过映射关系来定义，在根据感知请求的时间信息和/或终端的位置确定目标业务要求时，可以结合该映射关系来确定。
可选地，该映射关系可以包括至少一种业务要求与至少一个时段的对应关系，为方便区分和说明，下文记为第一映射关系。表四示出了第一映射关系的一个示例。
表四
可选地，该映射关系可以包括至少一种业务要求与至少一个区域的对应关系，为方便区分和说明，下文记为第二映射关系。
表五示出了第二映射关系的一个示例。
表五
可选地，该映射关系可以包括至少一种业务要求与区域和时段的至少一种组合的对应关系，为方便区分和说明，下文记为第三映射关系。
表六示出了第三映射关系的一个示例。
表六
应理解，上文结合表四至表六所示例的第一映射关系至第三映射关系仅为便于理解而示出，不应对本申请构成任何限定。上文所述的用于确定目标业务要求的映射关系可以包括第一映射关系、第二映射关系或第三映射关系中的一项或多项。此外，本申请也不限制这些映射关系的具体形式，例如可以为表格，也可以为其他形式，比如不同组合情况的枚举排列。本申请对此不作限定。
可以理解，表四中的业务要求A、业务要求B，表五、表六中的业务要求1、业务要求2都可以视为默认的业务要求的几个示例，换言之，默认的业务要求可以有一种，也可以有多种，本申请对此不作限定。
与上文所列举的映射关系相对应，SF根据感知请求的时间信息确定目标业务要求的一种可能的实现方式是，SF根据感知请求的时间信息和第一映射关系，确定目标业务要求。即，SF可以根据该第一映射关系确定与该时间信息对应的目标业务要求。例如，以AF发起感知请求的时间为例，SF根据该时间所属的时段，以及上述第一映射关系，可确定出与之对应的目标业务要求。
SF根据终端的位置确定目标业务要求的一种可能的实现方式是，SF根据终端的位置和第二映射关系，确定目标业务要求。即，SF可以确定该终端的位置在该至少一个区域中所属的区域，进而根据该第二映射关系确定与该区域对应的目标业务要求。
SF根据感知请求的时间信息和终端的位置确定目标业务要求的一种可能的实现方式是，SF根据感知请求的时间信息、终端的位置和映射关系，确定目标业务要求。即，SF可以确定该终端的位置所属的区域，以及该时间信息所属的时段，进而根据第三映射关系确定对应的目标业务要求。
可选地，该方法还包括：SF获取用于确定目标业务要求的映射关系。
用于确定目标业务要求的映射关系(例如包括第一映射关系、第二映射关系或第三映射关系中的一种或多种)可以是配置在SF中的，也可以配置在UDM中。相应地，在步骤5071a中，SF可以从本地获取该映射关系，也可以从UDM获取该映射关系。
SF从本地获取该映射关系的一种可能的实现是，该映射关系可通过人工存入该SF的存储器中，或者也可通过AF预先向SF发送，SF将接收到的映射关系存入存储器中。SF从本地获取该映射关系具体可以是指从存储器中获取该映射关系。
SF从UDM获取该映射关系的几种可能的实现如下：例如，在步骤5023a中UDM发送感知授权回复时可以携带该终端签约的感知权限和该映射关系，进而在步骤503中NEF可通过感知请求携带该终端签约的感知权限和该映射关系发送给SF。此时，SF获取用于确定目标业务要求的映射关系可通过步骤5023a和503来实现。又例如，在步骤507中SF从UDM获取该终端签约的感知权限的同时，也可以获取该映射关系，此时，SF获取用于确定目标业务要求的映射关系可通过步骤507来实现。当然，SF也可通过额外的信令向UDM请求该映射关系，本申请对此不作限定。
步骤508的另一种可能的实现方式如步骤508b所示：SF从UDM获取目标业务要求。
示例性地，步骤508b具体可包括如下步骤5081b中5083b：
5081b，SF向UDM发送业务要求请求。
5082b，UDM基于该业务要求请求确定目标业务要求。
5083b，UDM向SF发送该目标业务要求。
在步骤5081b中，一种可能的情况是，该业务要求请求可以是在SF确定终端允许被感知的情况下，向数据管理功能网元发送的，换言之，该业务要求请求的发送可以是终端允许被感知这一条件触发的。数据管理功能网元可以在接收到该业务要求请求后，确定目标业务要求，并发送给SF。也就是说，该业务要求请求的发送可用于隐式地指示该终端允许被感知。数据管理功能网元接收到该业务要求请求，便可默认该终端允许被感知。
另一种可能的情况是，该业务要求请求也可以是在SF确定终端是否允许被感知的结果的情况下发送的，并可通过该业务要求请求指示终端允许或不允许被感知。换言之，不管终端是否允许被感知，SF都可以向数据管理功能网元发送该业务要求请求。数据管理功能网元可以根据接收到的业务要求请求，先确定终端是否允许被感知，在终端允许被感知的情况下确定并向SF发送目标业务要求，而在终端不允许被感知的情况下不必确定目标业务要求。也就是说，数据管理功能网元并不一定要确定和发送目标业务要求。本实施例中，为方便介绍后续流程，假设该业务要求请求指示终端允许被感知，UDM可以基于该业务要求请求确定目标业务要求。
在步骤5082b中，UDM确定目标业务要求的实现方式与上文所示例的SF确定目标业务要求的实现方式相似，可以将默认的业务要求确定为目标业务要求，或者，将请求的业务要求确定为目标业务要求。如果UDM将默认的业务要求确定为目标业务要求，该UDM中可以预存有该默认的业务要求，或者将请求的业务要求定义为默认的业务要求。
可选地，该业务要求请求携带时间信息和/或位置信息。相应地，步骤5082b具体可以包括：UDM根据位置信息和/或时间信息确定目标业务要求。
其中，该位置信息指示终端的位置，该位置信息例如可以携带在业务要求请求中。该时间信息可用于指示如下一项或多项：AF发起感知请求的时间、SF接收到该感知请求的时间、该感知请求中携带的请求感知的时间、SF发送业务要求请求的时间、或UDM接收到该业务要求请求的时间。该时间信息(比如AF发起感知请求的时间、SF接收到该感知请求的时间、感知请求中携带的请求感知的时间、或SF发送业务要求请求的时间)可以携带在业务要求请求中，也可以根据UDM接收到该业务要求请求的时间确定。
UDM可以根据位置信息确定目标业务要求，也即，UDM可以根据终端的位置确定目标业务要求，一种可能的实现方式是，UDM可以根据终端的位置和第一映射关系来确定目标业务要求。UDM根据终端的位置确定目标业务要求的具体过程可参看上文步骤508a中SF根据终端的位置确定目标业务要求的相关说明，不再赘述。
UDM也可以根据时间信息确定目标业务要求，一种可能的实现方式是，UDM根据时间信息和第二映射关系确定目标业务要求。UDM根据时间信息确定目标业务要求的具体过程可参看上文步骤508a中SF根据时间信息确定目标业务要求的相关说明，不再赘述。
UDM还可以根据位置信息和时间信息确定目标业务要求，一种可能的实现方式是，UDM根据终端的位置、时间信息和第三映射关系，确定目标业务要求。UDM根据位置信息和时间信息确定目标业务要求的具体过程可参看上文步骤508a中SF根据位置信息和时间信息确定目标业务要求的相关说明，不再赘述。
在步骤508b所示出的这种实现方式中，UDM本地可能预配置有上述用于确定目标业务要求的映射关系。例如，该映射关系可通过人工存入该UDM的存储器中，或者也可通过AF预先向UDM发送，UDM将接收到的映射关系存入存储器中。图中虽未示出，但可以理解，UDM可以从本地的存储器中获取该映射关系。
在步骤509中，SF向AF发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求。
SF可以在目标业务要求与请求的业务要求不同的情况下，向AF发送业务要求确认请求。例如，SF可以在获取到目标业务要求后，与请求的业务要求进行对比，以确定目标业务要求与请求的业务要求是否相同。或者，SF也可以在步骤5064获取到感知通知反馈后，直接根据该感知通知反馈判断，是否需要对业务要求进行调整，比如降级或升级，也即确定目标业务要求与请求的业务要求不同，而并不一定要在获取到目标业务要求之后，通过与请求的业务要求对比才确定。
当然，如果SF确定目标业务要求与请求的业务要求相同，或者，如果SF确定不需要对请求的业务要求进行调整，或者，如果SF直接将请求的业务要求确定为目标业务要求，则无需执行步骤509至510，直接执行步骤511和512。
SF可以在该业务要求确认请求中携带目标业务要求，以请求采用该目标业务要求。
SF可以在该业务要求确认请求中携带目标业务要求，该业务要求请求用于将使用与感知请求中不同的业务要求执行感知流程指示给AF，用于请求AF确认可以或不可以采用该目标业务要求执行感知。
一种可能的情况是，该目标业务要求的级别与请求的业务要求的级别不同，比如，目标业务要求的级别低于请求的业务要求的级别，此时可将该业务要求确认请求理解为用于请求AF确认可以或不可以对执行感知的业务要求进行降级，该业务要求确认请求也可以称降级确认请求。
另一种可能的情况是，该目标业务要求的级别与请求的业务要求的级别不同，比如，目标业务要求的级别高于请求的业务要求的级别，此时可将该业务要求确认请求理解为用于请求AF确认可以或不可以对执行感知的业务要求进行升级，该业务要求确认请求也可以称升级确认请求。
需要说明的是，业务要求的级别可以根据由该业务要求对应的各项指标的值来确定。该业务要求对应的指标可以是包含在该业务要求中的，也可以是由该业务要求指示的，或者还可以是由该业务要求转化成的KPI中的指标，本申请对此不作限定。
目标业务要求的级别低于请求的业务要求的级别的几个示例如下：比如，目标业务要求对应的指标中感知位置精度为1m，请求的业务要求对应的指标中感知位置精度为1mm，由于1mm的精度相对于1m的精度来说，精度更高，因此可认为该目标业务要求的级别低于请求的业务要求的级别。又比如，目标业务要求对应的指标中感知分辨率为5m，请求的业务要求对应的指标中感知分辨率为1m，由于1m的感知分辨率相对于5m的感知分辨率来说，精度更高，因此可认为该目标业务要求的级别低于请求的业务要求的级别。又比如，目标业务要求对应的指标中最大感知服务时延为0.5ms，请求的业务要求对应的指标中最大感知服务时延为0.2ms，由于0.2ms的时延相对于0.5ms的时延来说，时延更短，因此可认为目标业务要求的级别低于请求的业务要求的级别。
目标业务要求的级别高于请求的业务要求的级别的几个示例如下：比如，目标业务要求对应的指标中感知位置精度为1mm，请求的业务要求对应的指标中感知位置精度为1m，由于1mm的精度相对于1m的精度来说，精度更高，因此可认为该目标业务要求的级别高于请求的业务要求的级别。又比如，目标业务要求对应的指标中感知分辨率为1m，请求的业务要求对应的指标中感知分辨率为5m，由于1m的感知分辨率相对于5m的感知分辨率来说，精度更高，因此可认为该目标业务要求的级别高于请求的业务要求的级别。又比如，目标业务要求对应的指标中最大感知服务时延为0.2ms，请求的业务要求对应的指标中最大感知服务时延为0.5ms，由于0.2ms的时延相对于0.5ms的时延来说，时延更短，因此可认为目标业务要求的级别高于请求的业务要求的级别。
当然，SF也可以在目标业务要求与请求的业务要求不同的情况下，基于目标业务要求发起对终端的感知流程，而不与AF确认是否同意采用目标业务要求。比如，在该目标业务要求的级别高于请求的业务要求的情况下，基于目标业务要求发起对终端的感知流程，而不与AF确认是否同意采用目标业务要求。此情况下，SF也不必确定该目标业务要求是否与请求的业务要求相同。换言之，步骤508至步骤510为可选的步骤，而并不一定要执行。
在步骤510中，AF向SF发送业务要求确认回复，该业务要求确认回复指示同意或不同意采用目标业务要求。
AF可以结合业务需求等因素，确定是否同意采用目标业务要求，并通过业务要求确认回复向SF指示是否同意采用该目标业务要求。
如果该业务要求确认回复指示同意采用目标业务要求，则可执行步骤511和512；如果该业务要求确认回复指示不同意采用目标业务要求，则可执行步骤513。
在步骤511中，SF基于该目标业务要求发起对终端的感知流程。
示例性地，步骤511具体可以包括如下步骤5111至5112：
5111，SF基于目标业务要求确定对终端进行感知的KPI。
5112，SF基于该KPI发起对该终端的感知流程。
其中，目标业务要求可以为KPI，或者包括KPI，或者也可以包括用于确定KPI的信息，比如与KPI对应的标识或参数，等等。KPI用于描述需要以怎样的精确度获取到感知数据。示例性地，KPI可以包括如下一项或多项指标：置信区间、感知定位精度(包括垂直和水平)、感知速度精度(包括垂直和水平)、感知分辨率(包括区域和速度)、最大感知服务时延或刷新率。这些指标仅为KPI的一个示例，本申请并不限定KPI具体包含的指标。
如果目标业务要求为KPI或包括KPI，SF可以直接基于该目标业务要求获得对终端进行感知的KPI，进而发起对终端的感知流程。
如果目标业务要求包括用于确定KPI的信息，SF可以将该目标业务要求转化为KPI。换言之，SF基于目标业务要求确定对终端进行感知的KPI的一种可能的实现方式是将目标业务要求确定为对终端进行感知的KPI，另一种可能的实现方式是将目标业务要求转化为对终端进行感知的KPI。
在一种可能的实现方式中，该目标业务要求中可以包含与KPI对应的标识，SF可以根据该目标业务要求中的标识，将目标业务要求转化为对终端进行感知的KPI。一种可能的实现方式是，SF中预存有至少一种标识与至少一种KPI的对应关系，每种KPI可以包括一个或多个指标。SF可以根据该目标业务要求中包含的标识，从预存的对应关系中查找出与该标识对应的KPI。
在另一种可能的实现方式中，该目标业务要求中也可以包含与KPI对应的参数，SF可以根据该目标业务要求中的参数，将该目标业务要求转化为对终端进行感知的KPI。一种可能的实现方式是，SF中预存有至少一组参数与至少一种KPI的对应关系，每组参数可以包括一个或多个参数，每种KPI可以包括一个或多个指标。SF可以根据该目标业务要求中包含的一组参数，从预存的对应关系中查找出与该组参数对应的KPI。
可以是根据预先定义的业务要求与KPI的对应关系来转化，例如目标业务要求为特定标识，SF有预定义特定标识对应的KPI。也可以是将感知要求中的参数翻译为KPI的参数，例如感知要求中的参数与KPI的参数一一对应，SF将感知要求中的参数分别确定为对应的KPI参数。感知要求也可等同于KPI，即不需要SF进行翻译。
SF在确定出KPI后，就可以基于该KPI发起对终端的感知流程。
SF发起对终端的感知流程具体可以是，SF选择特定的感知节点(发送机和接收机)并指示感知节点使用该KPI对该终端发送和接收感知信号，并获取感知数据后确定感知结果。
下文表七示例性地示出了六种可能的感知模式，该六种感知模式是分别针对感知信号的发送机和接收机来区分的，具体为：RAN节点自发自收、RAN节点A发RAN节点B收、RAN节点发终端收、终端发RAN节点收、终端自发自收和终端A发终端B收。可以看到，发送机可以为终端，也可以为RAN节点；接收机可以为终端也可以为RAN节点。
表七
在本实施例中，SF可以采用其中的一种感知模式来发起对终端的感知流程。例如，根据选择的感知模式确定发送机和接收机，进而向发送机和接收机指示上述KPI。
关于SF发起对终端的感知流程的具体过程可参看已有技术，为了简洁，不作详述。
在步骤512中，SF向AF发送感知结果。
在完成对该终端的感知流程后，SF可通过NEF或UPF等网元向AF发送该感知结果。
在步骤513中，SF向AF发送拒绝消息，该拒绝消息用于指示拒绝感知请求。
如果SF在步骤505中确定终端不允许被感知，或者在步骤510中接收到业务要求确认回复指示不同意采用目标业务要求，则可以通过NEF向AF发送拒绝消息，以拒绝上述感知请求。
可选地，该拒绝消息指示拒绝感知请求的原因。示例性地，拒绝感知请求的原因可以是终端不允许被感知，或者，AF不同意采用目标业务要求，等等，不再列举。
一种可能的实现方式是，通过不同的原因值来指示不同的原因，则该拒绝消息中携带原因值，该原因值用于指示拒绝感知请求的原因。
此外，由于在融合架构下，UDM和SF可以通过同一个NEF与AF交互，因此上文步骤504中的拒绝消息的发送与步骤513中的拒绝消息的发送对于NEF来说可以为同一个发送步骤。
基于上述方案，SF在接收到感知请求时，可以先确定终端是否允许被感知，进而在允许的情况下获取用于确定对该终端进行感知的KPI的目标业务要求，从而使得对于终端发起的感知流程是与终端的感知权限相适应的，而不是盲目地直接根据AF网元或AS等请求的业务要求来确定对终端进行感知的KPI。又或者说，本申请可以以终端为粒度来获取目标业务要求。因此，考虑到不同终端的安全需求，灵活地根据不同终端的安全需求做出响应，而不是盲目地根据AF的感知请求，不区分终端地进行感知。此外，通过针对每个终端预配置业务要求与区域、时段、业务类型等的对应关系，使得SF可以根据被请求感知的终端以及该终端的位置、请求感知的时间、请求的业务类型等因素来确定目标业务要求，从而使得网络可以在不同区域、不同时段、不同业务类型下采用不同的业务要求来对终端进行感知，从而提供了更为灵活的网络开放能力。
上文结合图5示出了本申请提供的方法的一种可能的流程，图5所示的各个步骤仅为示例，并不代表一定要执行图5中的全部步骤，比如，步骤503和步骤504可择一执行，步骤511至512和步骤513可择一执行，步骤507a和步骤507b可择一执行，等等。各步骤的序号大小也并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定。
图6是本申请实施例提供的感知方法的另一示意性流程图。与图5所示的方法500不同，图6所示的方法600提供了另一种获取目标业务要求的处理逻辑。下文中重点描述与方法500中不同的步骤，与方法500中相同的步骤，以及相同术语的说明均可参看上文方法500中的相关描述，不再赘述。
如图6所示，该方法600可以包括步骤601至611。下面详细说明方法600中的各个步骤。
在步骤601中，AF向NEF发送感知请求，该感知请求用于请求对终端进行感知。
在步骤602中，NEF从UDM获取对感知请求的授权。
可选地，步骤602具体包括如下步骤6021至6023：
步骤6021，NEF向UDM发送感知授权请求，该感知授权请求用于请求UDM授权该感知请求。
步骤6022，UDM根据终端签约的感知权限，确定该终端允许或不允许被感知。
步骤6023，UDM向NEF发送感知授权回复，该感知授权回复用于指示授权或拒绝授权该感知请求。
在步骤603中，NEF向SF发送感知请求。
在步骤604中，NEF向AF发送拒绝消息，该拒绝消息用于拒绝感知请求。
在步骤605中，SF获取终端签约的感知权限。
关于步骤601至605的具体过程与方法500中的步骤501至504，及步骤506的具体过程相同，可参看上文方法500中步骤501至504，及步骤507的相关描述，不再赘述。
在步骤606中，SF获得终端的感知通知反馈。SF可以通过发送感知通知请求，来获得终端的感知通知反馈。其中，该感知通知请求用于请求终端回复是否同意被感知。可选地，该步骤606具体包括：SF发送感知通知请求；SF根据该感知通知请求的响应消息获得该终端的感知通知反馈。
图中从设备交互的角度示出了步骤606的一种可能的实现方式。示例性地，可选地，步骤606具体包括如下步骤6061至6064：
步骤6061，SF向AMF发送感知通知请求。
步骤6062，AMF向终端转发该感知通知请求，以请求获取终端的回复。
步骤6063，SF接收感知通知请求的响应消息，该感知通知请求的响应消息指示终端回复同意被感知、终端回复不同意不感知或终端未回复。
步骤6064，SF根据该感知通知请求的响应消息获得感知通知反馈。
步骤606的具体过程与方法500中的步骤506的具体过程相似，可参看方法500的步骤506中的相关描述。与方法500不同，SF可以在未确定终端允许被感知的情况下获取目标业务要求，因此，SF并不需要先确定终端是否允许被感知，而是可以直接执行步骤607。
在步骤607中，SF获取目标业务要求。
在本申请实施例中，目标业务要求与终端的感知权限相关，包括：目标业务要求是在确定该终端允许被感知的情况下获取的，和/或，该目标业务要求是根据终端的感知权限确定的。本实施例主要提供了根据终端的感知权限确定目标业务要求的处理流程。
换言之，在本实施例中，SF并不需要在确定终端是否允许被感知的情况下，获取目标业务要求。具体地，目标业务要求是根据终端的感知通知反馈和/或终端签约的感知权限等获取的。
步骤607的一种可能的实现方式如步骤607a所示：SF确定目标业务要求。
SF可以根据终端签约的感知权限和/或终端的感知通知反馈，确定目标业务要求。也就是说，SF可以确定出与该终端签约的感知权限和/或感知通知反馈相对应的目标业务要求。
在一种可能的实现方式中，终端签约的感知权限和/或终端的感知通知反馈对应的目标业务要求可通过映射关系来定义。该映射关系指示至少一种业务要求与终端签约的感知权限和终端的感知通知反馈的至少一种组合的对应关系。SF可以根据上述映射关系，以及该终端签约的感知权限或终端的感知通知反馈中的一项或多项，确定目标业务要求。
可选地，该映射关系包括至少一种业务要求与终端签约的感知权限和感知通知反馈的至少一种组合，为便于区分和说明，下文记为第四映射关系。
为便于理解，表八示出了该第四映射关系的一个示例。
表八
对于每个终端来说，该第四映射关系可以包括表八中所示出的多组对应关系中的一组。
可以看到，表八所示的第四映射关系中，索引1和2对应的两组对应关系中，业务要求与终端签约的感知权限对应，因此可根据该终端签约的感知权限确定目标业务要求，而不需结合感知通知反馈。图中虽未示出，但可以理解，第四映射关系还可以包括感知通知反馈与业务要求的对应关系，此时也可根据终端的感知通知反馈确定目标业务要求，而不需结合终端签约的感知权限。
进一步地，SF还可以进一步结合终端的位置和/或时间信息来确定目标业务要求。换言之，上述映射关系包括至少一种业务要求与以下一项或多项的至少一种组合的对应关系：终端签约的感知权限、终端的感知通知反馈、区域、或时段。
可选地，该映射关系包括至少一种业务要求与终端签约的感知权限、感知通知反馈和区域的至少一种组合，为便于区分和说明，下文记为第五映射关系。
为便于理解，表九示出了该第五映射关系的一个示例。
表九

对于每个终端来说，该第五映射关系可以包括表九中所示出的多组对应关系中的一组或多组。
可选地，该映射关系包括至少一种业务要求与终端签约的感知权限、感知通知反馈和时段的至少一种组合，为便于区分和说明，下文记为第六映射关系。
为便于理解，表十示出了该第六映射关系的一个示例。
表十
对于每个终端来说，该第六映射关系可以包括表十中所示出的多组对应关系中的一组或多组。
可选地，该映射关系包括至少一种业务要求与终端签约的感知权限、感知通知反馈、时段和区域的至少一种组合，为便于区分和说明，下文记为第七映射关系。
为便于理解，表十一示出了该第七映射关系的一个示例。
表十一
对于每个终端来说，该第七映射关系可以包括表十一中所示出的多组对应关系中的一组或多组。
更进一步地，上述第四映射关系、第五映射关系、第六映射关系和第七映射关系还可以与业务类型对应。也就是说，表八、表九、表十和表十一所示的映射关系可以是与某一种业务类型对应的映射关系，第四映射关系、第五映射关系、第六映射关系和第七映射关系还可以包括与其他一种或多种业务类型对应的映射关系，为了简洁，这里不再列表示例。可以理解，如果上述各映射关系与业务类型对应，SF可以根据感知请求指示的请求的业务类型，来确定映射关系，进而根据映射关系来确定目标业务要求。
另外，表八、表九、表十和表十一中所示的业务要求1和业务要求2都可以理解为默认的业务要求。在本实施例中，默认的业务要求也可以划分为多个级别，比如业务要求1的级别高于业务要求2的级别。SF可以根据终端签约的感知权限和感知通知反馈来从中选择一个业务要求作为目标业务要求。其中，关于业务要求的级别的具体内容可参看上文方法500的步骤509中的相关说明，不再赘述。
以默认的业务要求被划分为两个级别(即，包括业务要求1和业务要求2)为例。一种可能的设计是，该业务要求1和业务要求2都可以是预配置的。另一种可能的设计是，该业务要求1为请求的业务要求，或者说业务要求1不需要预配置，业务要求2为预配置的，此时也可以称业务要求1为请求的业务要求。
表中的业务要求1和业务要求2仅为示例，默认的业务要求也可以被划分为更多个级别，或者不划分级别，此时表八、表九、表十和表十一分别所示例的第四映射关系、第五映射关系、第六映射关系和第七映射关系也可以随之调整，为了简洁，这里不再列表示例。
可以理解，对默认的业务要求不区分级别，可以使得网络侧的处理更为简单。对默认的业务要求定义多个级别，可以使得网络侧根据终端不同的感知通知反馈，灵活地选择业务要求，从而可以兼顾终端的安全需求和AF的业务需求，提供较好的使用体验。
还需要说明的是，由于在方法600中，SF并未预先确定终端是否允许被感知，而终端有可能回复不同意被感知，也即终端不允许被感知。因此，在上文表八、表九、表十和表十一分别示出的第四映射关系、第五映射关系、第六映射关系和第七映射关系中，与终端签约的感知权限与感知通知反馈的一些组合对应的业务要求可定义为拒绝感知请求，或者，设置为预定义值(比如“0”或者“空值(NULL)”)，以指示拒绝感知请求。这些组合可包括：终端签约的感知权限为“不允许被感知”，感知通知反馈为“N/A”；终端签约的感知权限为“需要通知终端、在终端回复同意或未回复的情况下允许被感知；需要通知终端、在终端回复不同意的情况下不允许被感知”，感知通知反馈为“回复不同意被感知”；终端签约的感知权限为“需要通知终端、在终端回复不同意或未回复的情况下不允许被感知；需要通知终端、在终端回复同意的情况下允许被感知”，感知通知反馈为“回复不同意被感知”。
下面就分别结合前述的第四映射关系、第五映射关系和第六映射关系，举例说明SF确定目标业务要求的过程。
在一种实现方式中，SF根据终端的感知通知反馈、终端签约的感知权限和第四映射关系确定目标业务要求。
以表八所示的第四映射关系为例。
例如，该终端签约的感知权限为不允许被感知，则SF可确定拒绝感知请求。
又例如，该终端签约的感知权限为：需要通知终端，在终端回复同意或未回复的情况下允许被感知。如果终端的感知通知反馈指示终端未回复，则SF可确定目标业务要求为业务要求2。
再例如，该终端签约的感知权限为：需要通知终端、仅在终端回复同意的情况下允许被感知。如果终端的感知通知反馈为终端回复同意被感知，则SF可确定目标业务要求为业务要求1。
在另一种实现方式中，SF根据终端的感知通知反馈、终端签约的感知权限、终端的位置和第五映射关系确定目标业务要求。其中，终端的位置可通过发起对终端的定位流程得到。
以表九所示的第五映射关系为例。
例如，该终端的位置属于区域2，则该区域2中终端签约的感知权限为允许被感知，SF可确定目标业务要求为业务要求1。
又例如，该终端的位置属于区域4，则该区域4中终端签约的感知权限为：需要通知终端、在终端回复同意或未回复的情况下允许被感知。如果终端的感知通知反馈为终端未回复，则SF可确定目标业务要求为业务要求2。
在又一种实现方式中，SF根据终端的感知通知反馈、终端签约的感知权限、感知请求的时间信息和第六映射关系确定目标业务要求。其中，终端的位置可通过发起对终端的定位流程得到。该感知请求的时间信息可用于指示：AF发起感知请求的时间或SF接收到该感知请求的时间。
以表十所示的第六映射关系为例。
例如，SF接收到该感知请求的时间属于时段C，则该时段C内终端签约的感知权限为允许被感知、需要通知终端但无需终端回复，SF可确定目标业务要求为业务要求1。
又例如，SF接收到该感知请求的时间属于时段E，则该时段E内终端签约的感知权限为：需要通知终端、仅在终端回复同意的情况下允许被感知。如果终端未回复，则SF可确定目标业务要求为拒绝感知请求。
以表十一所述的第七映射关系为例。
例如，SF接收到该感知请求的时间属于时段C，且终端的位置属于区域3，则该时段C和区域3对应的终端签约的感知权限为允许被感知、需要通知终端但无需终端回复，SF可确定目标业务要求为业务要求1。
又例如，SF接收到该感知请求的时间属于时段E，且终端的位置属于区域5，则该时段E和区域5对应的终端签约的感知权限为：需要通知终端、仅在终端回复同意的情况下允许被感知。如果终端未回复，则SF可确定目标业务要求为拒绝感知请求。
上文结合表八、表九、表十和表十一所示的第四映射关系、第五映射关系、第六映射关系和第七映射关系，对SF确定目标业务要求的过程的举例仅为示例，不应对本申请构成任何限定。
可选地，该方法还包括：SF获取用于确定目标业务要求的映射关系。
该映射关系可以是配置在SF中的，也可以预配置在UDM中。相应地，SF可以从本地获取该映射关系，也可以从UDM获取该映射关系。
SF从本地获取该映射关系的一种可能的实现是，该映射关系可通过人工存入该SF的存储器中，或者也可通过AF预先向SF发送，SF将接收到的映射关系存入存储器中。SF从本地获取该映射关系具体可以是指从存储器中获取该映射关系。
SF从UDM获取该映射关系的几种可能的实现如下：例如，在步骤6023a中UDM发送感知授权回复时可以携带该终端签约的感知权限和该映射关系，进而在步骤603中NEF可通过感知请求携带该终端签约的感知权限和该映射关系发送给SF。此时，SF获取用于确定目标业务要求的映射关系可通过步骤6023a和603来实现。又例如，在步骤606中SF从UDM获取该终端签约的感知权限的同时，也可以获取该映射关系，此时，SF获取用于确定目标业务要求的映射关系可通过步骤605来实现。当然，SF也可通过额外的信令向UDM请求该映射关系，本申请对此不作限定。
步骤607的另一种可能的实现方式如步骤607b所示，SF从UDM请求目标业务要求。
示例性地，步骤607b具体可包括如下步骤6071b至6073b：
6071b，SF向UDM发送业务要求请求，该业务要求请求中携带终端的感知通知反馈。
6072b，UDM基于该业务要求请求确定目标业务要求。
6073b，UDM向SF发送该目标业务要求。
与方法500中的步骤507b不同，SF向UDM发送的业务要求请求中携带终端的感知通知反馈，换句话说，该业务要求请求并不一定是在终端允许被感知的情况下发送的，且该业务要求请求也不用于指示终端允许被感知。UDM可以根据该终端的感知通知反馈、该终端签约的感知权限和映射关系来确定目标业务要求。
UDM根据该终端的感知通知反馈、该终端签约的感知权限和映射关系来确定目标业务要求的具体过程，与SF该终端的感知通知反馈、该终端签约的感知权限和映射关系来确定目标业务要求的具体过程相似，例如可以根据终端的感知通知反馈、终端签约的感知权限和第四映射关系来确定，或者，根据终端的感知通知反馈、终端签约的感知权限、终端的位置和第五映射关系来确定，或者，根据终端的感知通知反馈、终端签约的感知权限、时间信息和第六映射关系来确定，该时间信息可以是感知请求的时间信息，可用于指示AF发起感知请求的时间或SF接收到该感知请求的时间，也可以是业务要求请求的时间信息，可用于指示SF发送业务要求请求的时间或UDM接收到该业务要求请求的时间等。
关于UDM根据该终端的感知通知反馈、该终端签约的感知权限和映射关系来确定目标业务要求的更具体的内容可参看上文步骤607a的相关描述，不再赘述。
当然，UDM也可以根据该终端签约的感知权限和/或感知通知反馈，确定终端允许或不允许被感知，进而在终端允许被感知的情况下确定目标业务要求。此情况下，UDM可以采用与步骤607a中类似的方式，根据终端签约的感知权限和感知通知反馈，确定目标业务要求，还可以结合时间信息和/或位置信息，确定目标业务要求；也可以采用如方法500的步骤5082b中的方式，将默认的业务要求确定为目标业务要求，或者，将请求的业务要求确定为目标业务要求，或者，根据时间信息和/或位置信息，确定目标业务要求。本申请对此不作限定。
可以理解的是，如果SF获取到的目标业务要求为拒绝感知请求，则可以跳过步骤608至611，直接执行步骤612，SF发送拒绝消息。
在步骤608中，SF向AF发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求。
在步骤609中，AF向SF发送业务要求确认回复，该业务要求确认回复指示同意或不同意采用目标业务要求。
在步骤610中，SF基于该目标业务要求发起对终端的感知流程。
在步骤611中，SF向AF发送感知结果。
在步骤612中，SF向AF发送拒绝消息，该拒绝消息用于指示拒绝感知请求。
关于步骤608至步骤612的具体过程可参看上文方法500中步骤509至513的相关描述，不再赘述。
可以理解，SF也可以在目标业务要求与请求的业务要求不同的情况下，基于目标业务要求发起对终端的感知流程，而不与AF确认是否同意采用目标业务要求。此情况下，SF也不必确定该目标业务要求是否与请求的业务要求相同。换言之，步骤609至610为可选的步骤，而并不一定要执行。
基于上述方案，SF在接收到感知请求时，可以先获取终端的感知通知反馈，进而获取用于对该终端进行感知的KPI的目标业务要求从而使得对于终端发起的感知流程是与终端的感知权限相适应的，而不是盲目地直接根据AF网元或AS等请求的业务要求来确定对终端进行感知的KPI。又或者说，本申请可以与终端的感知权限相关，以终端为粒度来获取目标业务要求。因此，网络侧考虑了不同终端的安全需求，灵活地根据不同终端的安全需求对感知请求做出响应，而不是盲目地根据AF的感知请求，不区分终端地进行感知。此外，通过针对每个终端预配置业务要求与区域、时段、业务类型等的对应关系，使得SF可以根据被请求感知的终端以及该终端的位置、请求感知的时间、请求的业务类型等因素来确定目标业务要求，从而使得网络可以在不同区域、不同时段、不同业务类型下采用不同的业务要求来对终端进行感知，从而提供了更为灵活的网络开放能力。
上文结合图6示出了本申请提供的方法的一种可能的流程，图5所示的各个步骤仅为示例，并不代表一定要执行图6中的全部步骤，比如，步骤603和步骤604可择一执行，步骤610至611和步骤612可择一执行，步骤607a和步骤607b可择一执行，等等。各步骤的序号大小也并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定。
从上文结合图5和图6所示的方法可以看出，目标业务要求可以是在终端允许被感知的情况下确定的，也可以是根据终端签约的感知权限和终端的感知通知反馈确定，而终端允许或不允许被感知正是根据终端签约的感知权限和/或感知通知反馈确定的，终端允许或不允许被感知又可以通过终端的感知权限来指示。因此，总体而言，目标业务要求与终端的感知权限相关。
上文结合图5和图6所示出的流程中，以AF、NEF、UDM、SF及终端等的交互为例描述了本申请提供的感知方法，但这不应对本申请构成任何限定。在另一种可能的架构中，网络侧可包括感知服务端(或者称感知服务器)，终端可安装感知客户端(sensing client)。感知服务端可以理解成网络提供的位于协议栈上层的感知服务平台，感知客户端和以理解成在UE中位于协议栈上层的感知服务平台，感知服务端和感知客户端之间可以实现用户面的交互。该感知服务端可以视为用于对接外部应用(比如AF或AS)的功能网元，该感知服务端与AS之间也可以实现用户面的交互。考虑到网络可以提供多种感知功能，而应用的感知请求可能涉及多种或多次网络提供的感知功能，因此为了避免外部应用(如AF或AS)需要将其感知请求拆分成多种或多次网络提供的感知功能进行请求，网络可以使用感知服务端来代理应用的感知请求与网络提供的多种或多次感知功能。具体地，该感知服务端用于接收外部应用(AF或AS)的感知要求，并根据该感知要求进一步的与网络和UE进行交互并反馈感知结果。
在本申请实施例中，该感知服务端可用于实现图5或图6中所示流程中的SF部分功能，该感知客户端可用于实现图5或图6中所示流程中终端的功能。为方便理解，下面结合图7和图8来说明。
图7是本申请实施例提供的感知方法的又一示意性流程图。图7与图5所示的方法500的处理流程相似，与方法500中相同或相似的步骤，以及相同术语的说明均可参看上文方法500中的相关描述，不再赘述。
如图7所示，该方法700可以包括步骤701至713。下面详细说明方法700中的各个步骤。
在步骤701中，AS向感知服务端发送第一感知请求，该第一感知请求用于请求对终端进行感知。
AS可以与感知服务端进行用户面的交互，因此该第一感知请求为用户面的消息。示例性地，该第感知请求携带终端的外部标识，以及如下一项或多项：AS的标识、请求的业务要求或请求的业务类型。
AS向感知服务端发送第一感知请求的过程与上文方法500的步骤501中AF向NEF发送感知请求的过程相似，可参看上文方法500的步骤501中的相关说明，不再赘述。
在步骤702中，感知服务端从UDM获取对感知请求的授权。
示例性地，步骤702可以包括如下步骤7021至7023：
步骤7021，感知服务端向UDM发送感知授权请求，该感知授权请求用于请求UDM授权该第一感知请求，或用于请求UDM对该第一感知请求进行授权检查。
步骤7022，UDM根据终端签约的感知权限，确定该终端允许或不允许被感知。
步骤7023，UDM向感知服务端发送感知授权回复，该感知授权回复用于指示授权或拒绝授权该第一感知请求。
如果感知授权回复指示拒绝授权该第一感知请求，则可执行步骤703；如果感知授权回复指示授权第一感知请求，则可执行步骤704至713中的部分步骤。
可选地，在感知授权回复指示授权第一感知请求时，该感知授权回复还可携带如下一项或多项：终端的SUPI、终端签约的感知权限或用于确定目标业务要求的映射关系。
可选地，在感知授权回复指示拒绝授权第一感知请求时，该感知授权回复还可指示拒绝的原因。
关于步骤702的更详细的说明可参看方法500的步骤502中的相关内容，不再赘述。
在步骤703中，感知服务端向AS发送拒绝消息。
感知服务端向AS发送拒绝消息的具体过程与方法500的步骤503中NEF向AF发送拒绝消息的具体过程相似，可参看方法500的步骤503中的相关说明，不再赘述。
在步骤704中，感知服务端确定终端是否允许被感知。
感知服务端确定终端允许或不允许被感知的具体过程与方法500的步骤505的具体过程相似，可参看上文方法500的步骤505中的相关说明，不再赘述。
可选地，该方法还包括步骤705：感知服务端获得终端的感知通知反馈。
感知服务端可通过发送感知通知请求，来获得感知通知反馈。其中，该感知通知请求用于请求终端回复是否同意被感知。可选地，步骤705具体包括：感知服务端发送感知通知请求；感知服务端根据感知通知请求的响应消息获得感知通知反馈。
与方法500和600不同，感知服务端可以与安装在终端的感知客户端进行用户面的交互，而不必通过AMF、RAN节点的中转来交互。因此，感知服务端可以向感知客户端发送该感知通知请求，并从该感知客户端接收感知通知请求的响应消息。
图中从设备交互的角度示出了步骤705的一种可能的实现方式。示例性地，步骤705包括如下步骤7051至7054：
步骤7051，感知服务端向感知客户端发送感知通知请求。
步骤7052，感知客户端向感知服务端发送感知通知请求的响应消息，该感知通知请求的响应消息指示终端回复同意被感知、终端回复不同意被感知或终端未回复。
步骤7053，感知服务端根据该感知通知请求的响应消息获得感知通知反馈。
示例性地，感知客户端在接收到该感知服务端发送的感知通知请求后，可以将该感知通知请求发送至操作系统(operation system，OS)，以请求OS获取并反馈用户的回复。OS侧可以在获取到用户的回复后，对该感知通知请求作出回复，比如回复同意被感知，或不同意被感知，也可以在未获取到用户的回复的情况下，不作出回复。
一种可能的情况是，感知客户端可能接收到OS侧的回复，也可能未接收到OS侧的回复，感知客户端可以通过向感知服务端发送感知通知请求的响应消息指示终端回复同意被感知、或指示终端回复不同意被感知、或指示终端未回复。感知服务端可以根据来自感知客户端的感知通知请求的响应消息，来获得感知通知反馈，进而根据该终端签约的感知权限和该感知通知反馈来确定终端是否允许被感知。
另一种可能的情况是，感知客户端可以在接收到OS侧的回复的情况下，通过向感知服务端发送的感知通知请求的响应消息指示终端回复同意被感知、或指示终端回复不同意被感知。感知客户端也可能未获取到OS侧的回复，此时感知客户端不向感知服务端发送感知通知请求的响应消息。而感知服务端可以根据本地的计时器到期来确定终端未回复。换言之，步骤7052并不一定会执行，感知服务端可以根据来自感知客户端的感知通知请求的响应消息来获得感知通知反馈，具体可以包括：感知服务端可以根据来自感知客户端的感知通知请求的响应消息所指示的信息，或根据是否接收到来自感知客户端的感知通知请求的响应消息，来获得感知通知反馈。
关于步骤705的更详细的说明可参看方法500的步骤506中的相关内容，不再赘述。
在步骤706中，感知服务端获取目标业务要求。
可选地，步骤706包括：感知服务端确定目标业务要求。
在一种可能的设计中，SF中可以预存业务要求，该业务要求可以称为默认的(default)业务要求。SF可以在终端允许被感知的情况下，直接确定出目标业务要求。
在另一种可能的设计中，上述感知请求中可以携带请求的业务要求，SF可以在终端允许被感知的情况下将该请求的业务要求确定为目标业务要求。或者说，SF也可以将默认的业务要求定义为请求的业务要求，而不对默认的业务要求进行预配置。
在又一种可能的设计中，该目标业务要求可以根据第一感知请求的时间信息和/或终端的位置来确定。也就是说，感知服务端可以根据第一感知请求的时间信息和/或终端的位置确定目标业务要求。
感知服务端根据第一感知请求的时间信息和/或终端的位置确定目标业务要求的一种可能的实现方式是，感知服务端根据第一映射关系和第一感知请求的时间信息来确定目标业务要求，该第一映射关系可以包括至少一种业务要求与至少一个时段的对应关系。
感知服务端根据第一感知请求的时间信息和/或终端的位置确定目标业务要求的另一种可能的实现方式是，感知服务端根据终端的位置和第二映射关系来确定目标业务要求，该第二映射关系包括至少一种业务要求与至少一个区域的对应关系。
感知服务端根据第一感知请求的时间信息和/或终端的位置确定目标业务要求的一种可能的实现方式是的又一种可能的实现方式是，感知服务端根据第一感知请求的时间信息、终端的位置和第三映射关系，确定目标业务要求，该第三映射关系包括至少一种业务要求与区域和时段的至少一种组合的对应关系。
关于感知服务端根据第一感知请求的时间信息和/或终端的位置确定目标业务要求的更详细的说明可参看方法500的步骤508a中的相关内容，不再赘述。
可选地，步骤706包括：感知服务端从UDM获取该目标业务要求。
感知服务端从UDM获取该目标业务要求的具体过程与上文方法500的步骤508b中SF从UDM获取目标业务要求的具体过程相似，可参看步骤805b中的相关说明，不再赘述。
关于步骤706的更详细的说明可参看方法500的步骤508中的相关内容，不再赘述。
在步骤707中，感知服务端向AS发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求。
在步骤708中，AS向感知服务端发送业务要求确认回复，该业务要求确认回复指示同意或不同意采用目标业务要求。
步骤707至708的具体过程与方法500的步骤509至510相似，可参看方法500的步骤509至510的相关说明，不再赘述。
可以理解的是，如果该业务要求确认回复指示同意采用目标业务要求，则可执行步骤709至712；如果该业务要求确认回复指示不同意采用目标业务要求，则可执行步骤713。
在步骤709中，感知服务端向SF发送第二感知请求，该第二感知请求中携带目标业务要求。
感知服务端可以在AS同意采用目标业务要求的情况下，向SF发送第二感知请求，该第二感知请求中携带目标业务要求。
该感知服务端可以对步骤701中接收到的第一感知请求进行处理，得到第二感知要求。例如，感知服务端可以将第一感知请求中的终端的外部标识替换为终端的SUPI，并可将目标业务要求携带在第二感知请求中。换言之，该第二感知请求携带终端的SUPI和目标业务要求，以及如下一项或多项：AS的标识或请求的业务类型。
在步骤710中，SF基于该目标业务要求发起对该终端的感知流程。
SF可以在接收到该第二感知请求后，基于其中携带的目标业务要求，发起对该终端的感知流程。
关于SF基于目标业务要求发起对终端的感知流程的具体内容可参看方法500的步骤511中的相关说明，不再赘述。
在步骤711中，SF向感知服务端发送感知结果。
在完成对该终端的感知流程后，SF可以向感知服务端发送该感知结果。
在步骤712中，感知服务端向AS发送感知结果。
感知服务端可以通过用户面将该感知结果发送该AS。
在步骤713中，感知服务端向AS发送拒绝消息。
感知服务端可以通过用户面将拒绝消息发送该AS。
步骤711至713的具体过程与方法500的步骤512至513的具体过程相似，可参看方法500的步骤512至513中的相关说明，不再赘述。
上文结合图7示出了本申请提供的方法的又一种可能的流程，图7所示的各个步骤仅为示例，并不代表一定要执行图7中的全部步骤，比如，步骤703和步骤704可择一执行，步骤709至712和步骤713可择一执行，等等。各步骤的序号大小也并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定。
应理解，方法700与方法500具有相同的处理逻辑，因此方法700具有与方法500相似的技术效果，不再赘述。
图8是本申请实施例提供的感知方法的再一示意性流程图。图8所示的方法800与图6所示的方法600的处理流程相似，且与图7所示的方法700适用于相同的网络架构，与方法600或700中相同或相似的步骤，以及相同术语的说明可参看上文方法600或700中的相关描述；而方法700与图5所述的方法500的处理流程相似，与方法500中相同或相似的步骤，以及相同术语的说明也可参看上文方法500中的相关描述，不再赘述。
如图8所示，该方法800可以包括步骤801至813。下面详细说明方法800中的各个步骤。
在步骤801中，AS向感知服务端发送第一感知请求，该第一感知请求用于请求对终端进行感知。
在步骤802中，感知服务端从UDM获取对感知请求的授权。
感知服务端可通过向UDM发送感知授权请求，来获得UDM对该第一感知请求的授权。UDM可通过感知授权回复指示授权或拒绝授权该第一感知请求，在该感知授权回复指示拒绝授权的情况下，可执行步骤803，在该感知授权回复指示授权的情况下，可执行步骤804至813中的部分步骤。
在步骤803中，感知服务端向AS发送拒绝消息。
步骤801至803的具体过程与方法700中的步骤701至703相同，而方法700的步骤701至703的具体过程与方法500的步骤501至503相似，因此可参看方法500的步骤501至503，及方法700中的701至703中的相关说明，不再赘述。
在步骤804中，感知服务端获得终端的感知通知反馈。
感知服务端可通过发送感知通知请求，来获得终端的感知通知反馈。其中，该感知通知请求用于请求终端回复是否同意被感知。可选地，步骤804具体包括：感知服务端发送感知通知请求；感知服务端根据感知通知请求的响应消息获得终端的感知通知反馈。
与方法500和600不同，感知服务端可以与安装在终端的感知客户端进行用户面的交互，而不必通过AMF、RAN节点的中转来交互。因此，感知服务端可以向感知客户端发送该感知通知请求，并从该感知客户端接收感知通知请求的响应消息。
图中从设备交互的角度示出了步骤804的一种可能的实现方式。示例性地，步骤804包括如下步骤8041至8043：
步骤8041，感知服务端向感知客户端发送感知通知请求。
步骤8042，感知客户端向感知服务端发送感知通知请求的响应消息，该感知通知请求的响应消息中携带感知通知反馈。
步骤8043，感知服务端根据该感知通知请求的响应消息获得感知通知反馈。
关于步骤804的更详细的说明可参看方法700的步骤704中的相关内容，不再赘述。
与方法700不同，感知服务端可以在未确定该终端允许被感知的情况下获取目标业务要求，因此，感知服务端并不需要先确定终端是否允许被感知，而是直接执行步骤805。
在步骤805中，感知服务端获取目标业务要求。
在一种实现方式中，感知服务端可以根据终端签约的感知权限和/或终端的感知通知反馈，确定目标业务要求。在另一种实现方式中，感知服务端可以向数据管理功能网元发送业务要求请求，该业务要求请求中携带终端的感知通知反馈，数据管理功能网元可以根据终端签约的感知权限和/或终端的感知通知反馈，确定目标业务要求。
进一步地，目标业务要求还可结合终端的位置和/或时间信息确定。如果该目标业务要求由感知服务端通过向数据管理功能网元发送业务要求请求来请求获取，相应地，该业务要求请求中携带位置信息和/或时间信息。
在具体实现中，感知服务端或数据管理功能网元可以根据映射关系，以及如下一项或多项，确定目标业务要求：终端签约的感知权限、感知通知反馈、时段或区域。
感知服务端获取目标业务要求的具体过程与方法600的步骤607的具体过程相似，可参看上文方法600的步骤607的相关说明，不再赘述。在步骤806中，感知服务端向AS发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求。
在步骤807中，AS向感知服务端发送业务要求确认回复，该业务要求确认回复指示同意或不同意采用目标业务要求。
在步骤808中，感知服务端向SF发送第二感知请求，该第二感知请求中携带目标业务要求。
在步骤809中，SF基于该目标业务要求发起对该终端的感知流程。
SF可以在接收到该第二感知请求后，基于其中携带的目标业务要求，发起对该终端的感知流程。
关于SF基于目标业务要求发起对终端的感知流程的具体内容可参看方法500的步骤511中的相关说明，不再赘述。
在步骤810中，SF向感知服务端发送感知结果。
在完成对该终端的感知流程后，SF可以向感知服务端发送该感知结果。
在步骤811中，感知服务端向AS发送感知结果。
感知服务端可以通过用户面将该感知结果发送该AS。
在步骤812中，感知服务端向AS发送拒绝消息。
感知服务端可以通过用户面将拒绝消息发送该AS。
步骤806至812的具体过程与方法700的步骤707至713的具体过程相同，可参看方法700的步骤707至713中的相关说明，不再赘述。
上文结合图8示出了本申请提供的方法的又一种可能的流程，图8所示的各个步骤仅为示例，并不代表一定要执行图8中的全部步骤，比如，步骤803和步骤804至812可择一执行，步骤808至811和步骤812可择一执行，等等。各步骤的序号大小也并不意味着执行顺序的先后，各步骤的执行顺序应以其功能和内在逻辑确定。
应理解，方法800与方法600具有相同的处理逻辑，因此方法800具有与方法600相似的技术效果，不再赘述。
上文结合图5至图8示例性地示出了本申请提供的感知方法的几种可能的流程。不难看出，在图5至图8所示的实施例中，第二通信装置(比如图5和图6中的SF，或图7和图8中的感知服务端)都可以在接收到感知请求后，获取目标业务要求，而该目标业务要求与被感知请求的终端的感知权限相关。为方便理解，下面将结合图9，来对本申请提供的感知方法进行简单的说明。
图9是本申请实施例提供的感知方法的再一示意性流程图。图9设备交互的角度示出了该方法。如图9所示，该方法900包括步骤901至909。
下面详细说明方法900中的各个步骤。
在步骤901中，第二通信装置接收感知请求。
该感知请求可以是第一通信装置发出的、经由第三通信装置转发给该第二通信装置的。比如由AF发送至NEF(即，第三通信装置的一个示例)，再由NEF转发至SF。第三通信装置可以对该感知请求进行处理后再转发，也可以直接转发而不作处理。本申请对此不作限定。
该感知请求也可以是第一通信装置直接发送该第二通信装置的。比如，由AS发送至感知服务端。
示例性地，该感知请求可携带请求被感知的终端的外部标识以及如下一项或多项：AF的标识、请求的业务类型、请求的业务要求、或请求感知的时间信息。
步骤901可对应于上文方法500中的步骤501至503、方法600中的步骤601至603、方法700中的步骤701或方法800中的步骤801。因此，步骤901的具体过程可参看上文方法500、方法600、方法700或方法800中对应步骤的相关说明，不再赘述。
在步骤902中，第二通信装置获取目标业务要求，该目标业务要求与该终端的感知权限相关。
其中，该目标业务要求与终端的感知权限相关，包括：该目标业务要求是在确定该终端允许被感知的情况下获取的，和/或，该目标业务要求是根据终端的感知权限确定的。
因此，本申请中提供了至少两种处理逻辑来获取目标业务要求。
一种处理逻辑是，在确定终端允许被感知的情况下获取目标业务要求。可选地，该方法还包括步骤903：第二通信装置确定终端允许被感知。第二通信装置可以根据该终端签约的感知权限和/或终端的感知通知反馈来确定终端允许被感知。
在确定终端允许被感知的情况下，第二通信装置可以自行确定目标业务要求，如图中的902a所示，或者也可以从数据管理功能网元请求获取该目标业务要求，如图中的902b所示。该目标业务要求可根据终端的位置和/或时间信息来确定。
步骤903可对应于上文方法500中的步骤505或方法700中的步骤704。因此，步骤903的具体过程可参看上文方法500或700中对应步骤的相关说明，不再赘述。
在这种处理逻辑中，步骤902可对应于上文方法500中的步骤508或方法700中的步骤706。因此，步骤902的具体过程可参看上文方法500或700中对应步骤的相关说明，不再赘述。
另一种处理逻辑是，在不需要确定终端允许被感知的情况下获取目标业务要求，而该目标业务要求可以根据终端的感知权限确定，具体可根据终端签约的感知权限和终端的感知通知反馈确定。
在获得终端的感知通知反馈之后，第二通信装置可以自行确定目标业务要求，如图中的902a所示，或者也可以数据管理功能网元发送业务要求请求，该业务要求请求中携带感知通知反馈，用于请求获取目标业务要求将该发送至数据管理功能网元，如图中的902b所示。该目标业务要求可根据该终端签约的感知权限和/或感知通知反馈确定。进一步地，该目标业务要求还可以结合终端的位置和/或时间信息来确定。
在这种处理逻辑中，步骤902可对应于上文方法600中的步骤607或方法800中的步骤805。因此，步骤903的具体过程可参看上文方法600或800中对应步骤的相关说明，不再赘述。
应理解，上文所示例的两种处理逻辑仅为两种可能的实现方式，不应对本申请构成任何限定。不难看出，这两种处理逻辑本质上都与终端的感知权限相关，而终端的感知权限可以包括终端签约的感知权限和/或终端的感知通知反馈，因此也可以认为，目标业务要求是根据终端签约的感知权限和/或终端的感知通知反馈确定的。因此，在具体实现时，这两种处理逻辑可以单独使用，也可以结合使用，比如，数据管理功能网元在接收到携带终端的感知通知反馈的业务要求请求后，可以先根据终端签约的感知权限和/或终端的感知通知反馈确定出终端允许被感知，再确定出目标业务要求。本申请对此不作限定。
进一步地，在上文所示例的两种处理逻辑中，第二通信装置可先获得终端的感知通知反馈，比如在步骤903之前或者在步骤902之前，获得该终端的感知通知反馈。
可选地，该方法还包括步骤904，获得该终端的感知通知反馈，该感知通知反馈指示终端回复同意被感知、终端回复不同意被感知或终端未回复。示例性地，第二通信装置可通过发送感知通知请求来获得终端的感知通知反馈。
步骤904可对应于方法500中的步骤506、方法600中的步骤606、方法700中的步骤705或方法800中的步骤804，因此，步骤904的具体过程可参看前文方法500、方法600、方法700或方法800中对应步骤的相关说明，不再赘述。
可选地，该方法还包括步骤905，第二通信装置向第一通信装置发送业务要求确认请求，该业务要求确认请求用于请求采用目标业务要求。相应地，第一通信装置接收来自第二通信装置的业务要求确认请求。
第二通信装置可以在目标业务要求与感知请求中携带的请求的业务要求不同的情况下，向第一通信装置发送业务要求确认请求。
可选地，该方法还包括步骤906，第一通信装置向第二通信装置发送业务要求确认回复，该业务要求确认回复用于指示同意或不同意采用目标业务要求。相应地，第二通信装置接收来自第一通信装置的业务要求确认回复。
可选地，该方法还包括步骤907，第二通信装置基于目标业务要求发起对终端的感知流程。
如果该业务要求确认回复指示同意采用目标业务要求，第二通信装置可基于目标业务要求发起对终端的感知流程。
可选地，该方法还包括步骤908，第二通信装置向第一通信装置发送感知结果。相应地，第一通信装置接收来自第二通信装置的感知结果。
第二通信装置可以在获取到感知结果后，将该感知结果发送给第一通信装置。
可选地，该方法还包括步骤909，第二通信通信装置向第一通信装置发送拒绝消息，该拒绝消息用于拒绝第一通信装置的感知请求。相应地，第一通信装置接收来自第二通信装置的拒绝消息。
如果该业务要求确认回复指示不同意采用目标业务要求，第二通信装置可拒绝该感知请求。
步骤905至909可对应于方法500中的步骤509至513，方法600中的步骤608至612，方法700中的步骤707至713，以及方法800中的步骤806至812。因此，步骤905至909的具体过程可参看上文方法500、方法600、方法700或方法800中对应步骤的相关说明，不再赘述。
可选地，该方法还包括：第二通信装置从数据管理功能网元获取终端签约的感知权限和/或用于确定目标业务要求的映射关系。相应地，数据管理功能网元向第二通信装置发送该终端签约的感知权限和/或用于确定目标业务要求的映射关系。
在本申请提供的方案中，用于确定对终端进行感知的KPI的目标业务要求与终端的感知权限相关，从而使得对于终端发起的感知流程是与终端的感知权限相适应的，而不是盲目地直接根据AF网元或AS等请求的业务要求来确定对终端进行感知的KPI。又或者说，本申请可以以终端为粒度来获取目标业务要求。具体地，不同终端的目标业务要求可以根据各自对应的感知权限来确定。因此，考虑到不同终端的安全需求，灵活地根据不同终端的感知权限，获取不同的目标业务要求，进而基于不同的KPI对不同的终端发起感知流程，而不是盲目地根据AF网元或AS请求的业务要求，采用相同的KPI对所有被请求感知的终端进行感知。
以上，结合附图对本申请实施例提供的感知方法进行了详细说明。以下，结合附图对本申请实施例提供的装置进行详细说明。
图10至图11为本申请的实施例提供的可能的通信装置的示意性框图。这些通信装置可以用于实现上述方法实施例中第二通信装置的功能、数据管理功能网元的功能或第一通信装置的功能，因此也能实现上述方法实施例所具备的有益效果。
本申请提供的一个通信装置如图10所示，通信装置1000包括通信单元1010和处理单元1020。
一种可能的设计是，通信装置1000用于实现上述图5至图9中所示的方法实施例中任一个实施例中第二通信装置的功能。比如，该通知装置可以是如图9所示的方法实施例中的第二通信装置，或者，该通信装置可以是如图5或图6所示的方法实施例中的SF，或者也可以是如图7或图8所示的方法实施例中的感知服务端，也可以是配置在SF或感知服务端中的组件(如芯片、芯片系统、处理器等)，还可以是能够实现SF或感知服务端的部分或全部功能的逻辑模块或软件。
示例性地，该通信单元1010用于接收感知请求，所述感知请求用于请求对终端进行感知；该处理单元1020用于获取目标业务要求，所述目标业务要求用于确定对所述终端进行感知的KPI，所述目标业务要求与所述终端的感知权限相关，所述感知权限用于确定所述终端允许或不允许被感知。
可选地，该处理单元1020具体用于在确定所述终端允许被感知的情况下，获取所述目标业务要求。
可选地，该处理单元1020具体用于根据所述终端签约的感知权限和/或感知通知反馈，确定所述终端允许被感知，所述感知通知反馈指示所述终端回复同意被感知或所述终端未回复。
可选地，该通信单元1010还用于从数据管理功能网元获取终端签约的感知权限。
可选地，该通信单元1010还用于向数据管理功能网元发送业务要求请求，所述业务要求请求指示所述终端允许被感知；并用于接收来自所述数据管理功能网元的所述目标业务要求，所述目标业务要求基于所述业务要求请求确定。
可选地，该通信单元1010还用于向数据管理功能网元发送业务要求请求；并用于接收来自所述数据管理功能网元的所述目标业务要求，所述目标业务要求基于所述业务要求请求确定。
可选地，所述业务要求请求中携带感知通知反馈，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端未回复，所述感知通知请求用于请求所述终端回复同意或不同意被感知。
可选地，该通信单元1010还用于发送感知通知请求，所述感知通知请求用于请求所述终端回复同意或不同意被感知；处理单元1020还用于根据所述感知通知请求的响应消息获得所述感知通知反馈。
可选地，所述业务要求请求消息还包括所述终端的位置信息和/或所述感知请求的时间信息。
可选地，所述感知请求指示请求的业务类型，所述业务要求请求消息中还指示所述业务类型。
可选地，该处理单元1020具体用于根据所述终端的位置和/或所述感知请求的时间信息，确定所述目标业务要求。
可选地，该处理单元1020具体用于根据所述终端签约的感知权限、感知通知反馈和映射关系，确定所述目标业务要求，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端对所述感知通知请求未回复，所述感知通知请求用于请求所述终端回复是否同意被感知，所述映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
可选地，该通信单元1020还用于接收来自所述数据管理功能网元的所述映射关系。
可选地，所述感知请求来自第一通信装置，所述感知请求中还携带请求的业务要求，该通信单元1010还用于：向所述第一通信装置发送业务要求确认请求，所述业务要求确认请求用于请求采用所述目标业务要求，所述目标业务要求与所述请求的业务要求不同；接收来自所述第一通信装置的业务要求确认回复，所述业务要求确认回复指示同意或不同意采用所述目标业务要求；该处理单元1020还用于，在所述业务要求确认回复指示同意采用所述目标业务要求的情况下，基于所述目标业务要求发起对所述终端的感知流程；该通信单元1010还用于在所述业务要求确认回复指示不同意采用所述目标业务要求的情况下，向所述第一通信装置发送拒绝消息，所述拒绝消息用于拒绝所述感知请求。
可选地，该通信单元1010还用于在确定所述终端不允许被感知的情况下，向所述第一通信装置发送拒绝消息，所述拒绝消息用于拒绝所述感知请求。
可选地，该拒绝消息还指示拒绝所述感知请求的原因。
有关上述通信单元1010和处理单元1020更详细的描述可以直接参考图5至图9所示的方法实施例中相关描述直接得到，这里不加赘述。
一种可能的设计是，通信装置1000用于实现上述图5至图9中所示的方法实施例中任一个实施例中数据管理功能模块(比如UDM)的功能。比如，该通信装置可以是如图5至图8所示的方法实施例的任意一个实施例中的UDM，或者如图9所示的方法实施例中的数据管理功能网元，或者也可以是配置在UDM或其他数据管理功能网元中的组件(如芯片、芯片系统、处理器等)，还可以是能够实现UDM或其他数据管理功能网元的部分或全部功能的逻辑模块或软件。
示例性地，该通信单元1010用于接收来自第二通信装置的业务要求请求，所述业务要求请求用于请求获取目标业务要求，所述目标业务要求用于确定对终端进行感知的KPI；该处理单元1020用于确定所述目标业务要求，所述目标业务要求与所述终端的感知权限相关；该通信单元1010还用于向所述第二通信装置发送所述目标业务要求。
可选地，所述业务要求请求中携带感知通知反馈，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端对所述感知通知请求未回复，所述感知通知请求用于请求所述终端回复是否同意被感知。该处理单元1020具体用于根据所述终端的感知权限、所述感知通知反馈和映射关系，确定所述目标业务要求，所述映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
可选地，所述业务要求请求指示所述终端允许被感知以及如下一项或多项：所述终端的位置、感知请求的时间信息或所述业务要求请求的时间信息，所述感知请求用于请求对所述终端进行感知的。该处理单元1020具体用于根据如下一项或多项确定所述目标业务要求：所述终端的位置、所述感知请求的时间信息或所述业务要求请求的时间信息。
可选地，该通信单元1020还用于接收来自所述第二通信装置发送终端签约的感知权限。
示例性地，该通信单元1020用于：接收来自第三通信装置的感知授权请求，所述感知授权请求用于请求对感知请求授权，所述感知请求用于请求对终端进行感知；根据所述终端的感知权限，向所述第三通信装置发送感知授权回复，所述感知授权回复指示对所述感知请求授权，或拒绝对所述感知请求授权。
可选地，所述感知授权回复指示对所述感知请求授权，所述感知授权回复中携带所述终端签约的感知权限和/或用于确定目标业务要求的映射关系，所述目标业务要求用于确定对所述终端进行感知的KPI。
有关上述通信单元1010和处理单元1020更详细的描述可以直接参考图5至图9所示的方法实施例中相关描述直接得到，这里不加赘述。
需要说明的是，通信单元也可以称为收发单元、收发模块、收发器、收发机、或收发装置等。处理单元也可以称为处理器，处理单板，处理模块、或处理装置等。可选地，通信单元用于执行上述方法中第二通信装置或数据管理功能模块的发送操作和接收操作，可以将通信单元中用于实现接收功能的器件视为接收单元，将通信单元中用于实现发送功能的器件视为发送单元，即，通信单元包括接收单元和发送单元。
还需要说明的是，在一种可能的设计中，前述通信单元和/或处理单元可通过虚拟模块实现，例如处理单元可通过软件功能单元或虚拟装置实现，通信单元可以通过软件功能或虚拟装置实现。在另一种可能的设计中，处理单元或通信单元也可以通过实体装置实现，例如若该装置采用芯片/芯片电路实现，所述通信单元可以是输入输出电路和/或通信接口，执行输入操作(对应前述接收操作)、输出操作(对应前述发送操作)；处理单元为集成的处理器或者微处理器或者集成电路。
本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请实施例各个示例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。
本申请提供的另一通信装置如图11所示，通信装置1100包括至少一个处理器1110。该至少一个处理器1110可用于执行存储器中的计算机程序或指令，以实现图5至图9所示方法实施例中的任一实施例中第二通信装置(比如SF或感知服务端)执行的步骤、数据管理功能网元(比如UDM)执行的步骤或第一通信装置(比如AS或AF)执行的步骤。
可选地，通信装置1100还可以包括至少一个存储器1120，用于存储处理器1110执行的指令或存储处理器1110运行指令所需要的输入数据或存储处理器1110运行指令后产生的数据。该至少一个处理器1110和至少一个存储器1120可以分开设置。比如，各存储器可以与一个或多个处理器连接，使得所连接的处理器能够从存储器中读取信息，在存储器中存储和/或写入信息。或者，该至少一个处理器1110和至少一个存储器1120可以集成在一起，比如，一个处理器中可以集成有一个或多个存储器。
可选地，通信装置1100还包括接口电路1130，可用于传输数据和/或信令。该至少一个处理器1110和接口电路1130之间相互耦合。可以理解的是，接口电路1130可以为收发器、输入输出电路、总线、模块、管脚或其它类型的通信接口，其中，输入输出电路中的输入电路可用于接收，输出接口可用于发送。
可选地，该通信装置1100还包括供电电路1140，该供电电路1140可用于为该通信装置1100供电。
当通信装置1100用于实现图5至图9所示的方法时，处理器1111用于执行上述处理单元的功能，接口电路1120用于执行上述接收单元和/或发送单元的功能。接口电路1120用于发送还是接收，具体可以视该通信装置1100执行的方案中用于执行发送动作还是接收动作。
可以理解的是，该通信装置1100为通信设备(比如，SF、感知服务端、数据管理功能网元、AF或AS)时，接口电路1120可以为收发器，具体可包括发射器和接收器，发射器用于发送信号，接收器用于接收信号。该通信装置1100为应用于通信设备的芯片时，接口电路1120可以为输入输出电路、总线、模块、管脚或其它类型的通信接口，其中，输入输出电路中的输入电路可用于接收，输出接口可用于发送。
应理解，图11所示的通信装置1100中，处理器1110可对应于上文通信装置1000中的处理单元1020，接口电路1120可对应于上文通信装置1000中的通信单元1010。
还应理解，本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。本申请实施例中不限定上述至少一个处理器1110、至少一个存储器1120、接口电路1130以及供电电路1140之间的具体连接介质。本申请实施例在图11中以处理器1110、存储器1120、接口电路1130以及供电电路1140之间通过总线1150连接。总线1150在图11中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
可以理解的是，本申请的实施例中的处理器可以是中央处理单元(central processing unit，CPU)，还可以是其它通用处理器、数字信号处理器(digital signal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其它可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。
本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
本申请还提供一种通信系统，该通信系统包括前述的第一通信装置、第二通信装置或数据管理功能网元中的一项或多项。
示例性地，该通信系统包括SF和UDM。可选地，该通信系统还包括感知服务端。可选地，该通信系统还包括NEF。
本申请还提供一种计算机程序产品，该计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当该计算机程序被运行时，使得计算机执行如9所示的实施例中第二通信装置、数据管理功能网元或第一通信装置执行的方法，或使得计算机执行如图5至图8所示实施例的任一实施例中数据管理功能网元执行的方法，或使得计算机执行如图5或图6所示实施例中SF执行的方法，或使得计算机执行如图7或图8中感知服务端执行的方法。
本申请还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当该计算机程序被运行时，使得计算机执行如9所示的实施例中第二通信装置、数据管理功能网元或第一通信装置执行的方法，或使得计算机执行如图5至图8所示实施例的任一实施例中数据管理功能网元执行的方法，或使得计算机执行如图5或图6所示实施例中SF执行的方法，或使得计算机执行如图7或图8中感知服务端执行的方法。
本说明书中使用的术语“单元”、“模块”等，可用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。在本申请所提供的几个实施例中，应该理解到，所揭露的装置、设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
在上述实施例中，各功能单元的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令(程序)。在计算机上加载和执行该计算机程序指令(程序)时，全部或部分地产生按照本申请实施例所述的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。
该功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (39)

  1. 一种感知方法，其特征在于，包括：
    接收感知请求，所述感知请求用于请求对终端进行感知；
    获取目标业务要求，所述目标业务要求用于确定对所述终端进行感知的关键性能指标KPI，所述目标业务要求与所述终端的感知权限相关，所述感知权限用于确定所述终端允许或不允许被感知。
  2. 如权利要求1所述的方法，其特征在于，所述获取目标业务要求，包括：
    在确定所述终端允许被感知的情况下，获取所述目标业务要求。
  3. 如权利要求2所述的方法，其特征在于，所述确定所述终端允许被感知，包括：
    根据所述终端签约的感知权限和/或所述终端的感知通知反馈，确定所述终端允许被感知，所述感知通知反馈指示所述终端回复同意被感知或所述终端未回复。
  4. 如权利要求3所述的方法，其特征在于，所述方法还包括：
    发送感知通知请求，所述感知通知请求用于请求所述终端回复同意或不同意被感知；
    根据所述感知通知请求的响应消息获得所述感知通知反馈。
  5. 如权利要求3或4所述的方法，其特征在于，所述方法还包括：
    从数据管理功能网元获取所述终端签约的感知权限。
  6. 如权利要求1至5中任一项所述的方法，其特征在于，所述获取所述目标业务要求，包括：
    向数据管理功能网元发送业务要求请求；
    接收来自所述数据管理功能网元的所述目标业务要求，所述目标业务要求基于所述业务要求请求确定。
  7. 如权利要求6所述的方法，其特征在于，所述业务要求请求中携带感知通知反馈，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端未回复，所述感知通知请求用于请求所述终端回复同意或不同意被感知。
  8. 如权利要求6或7所述的方法，其特征在于，所述业务要求请求消息还包括所述终端的位置信息和/或所述感知请求的时间信息。
  9. 如权利要求6至8中任一项所述的方法，其特征在于，所述感知请求指示请求的业务类型，所述业务要求请求消息中还指示所述业务类型。
  10. 如权利要求2至5中任一项所述的方法，其特征在于，所述获取目标业务要求，包括：
    根据所述终端的位置和/或所述感知请求的时间信息，确定所述目标业务要求。
  11. 如权利要求1至5中任一项所述的方法，其特征在于，所述获取所述目标业务要求，包括：
    根据所述终端签约的感知权限、感知通知反馈和映射关系，确定所述目标业务要求，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端对所述感知通知请求未回复，所述感知通知请求用于请求所述终端回复是否同意被感知，所述映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
  12. 如权利要求11所述的方法，其特征在于，所述方法还包括：
    接收来自数据管理功能网元的所述映射关系。
  13. 如权利要求1至12中任一项所述的方法，其特征在于，所述感知请求来自第一通信装置，所述感知请求中还携带请求的业务要求，所述方法还包括：
    向所述第一通信装置发送业务要求确认请求，所述业务要求确认请求用于请求采用所述目标业务要求，所述目标业务要求与所述请求的业务要求不同；
    接收来自所述第一通信装置的业务要求确认回复，所述业务要求确认回复指示同意或不同意采用所述目标业务要求；以及
    在所述业务要求确认回复指示同意采用所述目标业务要求的情况下，基于所述目标业务要求发起对所述终端的感知流程；或
    在所述业务要求确认回复指示不同意采用所述目标业务要求的情况下，向所述第一通信装置发送拒绝消息，所述拒绝消息用于拒绝所述感知请求。
  14. 如权利要求1所述的方法，其特征在于，所述感知请求来自第一通信装置，所述方法还包括：
    在确定所述终端不允许被感知的情况下，向所述第一通信装置发送拒绝消息，所述拒绝消息用于拒绝所述感知请求。
  15. 如权利要求13或14所述的方法，其特征在于，所述拒绝消息还指示拒绝所述感知请求的原因。
  16. 一种感知方法，其特征在于，包括：
    接收来自第二通信装置的业务要求请求，所述业务要求请求用于请求获取目标业务要求，所述目标业务要求用于确定对终端进行感知的关键性能指标KPI；
    确定所述目标业务要求，所述目标业务要求与所述终端的感知权限相关；
    向所述第二通信装置发送所述目标业务要求。
  17. 如权利要求16所述的方法，其特征在于，所述业务要求请求中携带感知通知反馈，所述感知通知反馈指示所述终端对感知通知请求回复同意被感知或所述终端对所述感知通知请求未回复，所述感知通知请求用于请求所述终端回复是否同意被感知；以及
    所述确定所述目标业务要求，包括：
    根据所述终端的感知权限、所述感知通知反馈和映射关系，确定所述目标业务要求，所述映射关系包括感知权限和感知通知反馈的至少一种组合与至少一种业务要求的对应关系。
  18. 如权利要求16所述的方法，其特征在于，所述业务要求请求指示所述终端允许被感知以及如下一项或多项：所述终端的位置、感知请求的时间信息或所述业务要求请求的时间信息，所述感知请求用于请求对所述终端进行感知的；以及
    所述确定所述目标业务要求，包括：
    根据如下一项或多项确定所述目标业务要求：所述终端的位置、所述感知请求的时间信息或所述业务要求请求的时间信息。
  19. 如权利要求16至18中任一项所述的方法，其特征在于，所述方法还包括：
    向所述第二通信装置发送所述终端签约的感知权限。
  20. 如权利要求16至19中任一项所述的方法，其特征在于，所述方法还包括：
    接收来自第三通信装置的感知授权请求，所述感知授权请求用于请求对感知请求授权，所述感知请求用于请求对终端进行感知；
    根据所述终端的感知权限，向所述第三通信装置发送感知授权回复，所述感知授权回复指示对所述感知请求授权，或拒绝对所述感知请求授权。
  21. 如权利要求20所述的方法，其特征在于，所述感知授权回复指示对所述感知请求授权，所述感知授权回复中携带所述终端签约的感知权限和/或用于确定所述目标业务要求的映射关系。
  22. 一种感知方法，其特征在于，包括：
    接收感知授权请求，所述感知授权请求用于请求对感知请求授权，所述感知请求用于请求对终端进行感知；
    根据所述终端签约的感知权限，发送感知授权回复，所述感知授权回复指示对所述感知请求授权，或拒绝对所述感知请求授权。
  23. 如权利要求22所述的方法，其特征在于，所述感知授权回复指示对所述感知请求授权，所述感知授权回复中携带所述终端签约的感知权限和/或用于确定目标业务要求的映射关系，所述目标业务要求用于确定对所述终端进行感知的关键性能指标KPI。
  24. 如权利要求1至23中任一项所述的方法，其特征在于，所述终端签约的感知权限为：不允许被感知，允许被感知，允许被感知、需要通知所述终端但无需所述终端反馈，需要通知所述终端、在所述终端回复同意或不回复的情况下允许被感知，或者需要通知所述终端、仅在所述终端回复同意的情况下允许被感知。
  25. 一种感知方法，其特征在于，包括：
    接收来自第二通信装置的业务要求确认请求，所述业务要求确认请求用于请求采用目标业务要求，所述目标业务要求与请求的业务要求不同；
    向所述第二通信装置发送业务要求确认回复，所述业务要求确认回复指示同意或不同意采用所述目标业务要求。
  26. 如权利要求25所述的方法，其特征在于，所述方法还包括：
    接收来自所述第二通信装置的拒绝消息，所述拒绝消息用于拒绝感知请求，所述感知请求用于请求对终端进行感知。
  27. 如权利要求26所述的方法，其特征在于，所述拒绝消息还指示拒绝所述感知请求的原因。
  28. 一种感知方法，其特征在于，包括：
    第二通信装置接收感知请求，所述感知请求用于请求对终端进行感知；
    所述第二通信装置从数据管理功能网元获取目标业务要求，所述目标业务要求用于确定对所述终端进行感知的KPI。
  29. 如权利要求28所述的方法，其特征在于，所述第二通信装置从数据管理功能网元获取目标业务要求，包括：
    所述第二通信装置在确定所述终端允许被感知的情况下，向所述数据管理功能网元发送业务要求请求，所述业务要求请求指示所述终端允许被感知；
    所述数据管理功能网元确定所述目标业务要求；
    所述数据管理功能网元向所述第二通信装置发送所述目标业务要求。
  30. 如权利要求29所述的方法，其特征在于，所述目标业务要求携带如下一项或多项：所述终端的位置、所述感知请求的时间信息或所述业务要求请求的时间信息。
  31. 如权利要求29或30所述的方法，其特征在于，所述第二通信装置确定所述终端允许被感知，包括：
    所述第二通信装置根据所述终端签约的感知权限和/或所述终端的感知通知反馈，确定所述终端允许被感知，所述感知通知反馈指示所述终端回复同意被感知或所述终端未回复。
  32. 如权利要求31所述的方法，其特征在于，所述方法还包括：
    所述第二通信装置向所述终端发送感知通知请求，所述感知通知请求用于请求所述终端回复是否同意被感知；
    所述第二通信装置根据所述感知通知请求的响应消息获取所述感知通知反馈，所述感知通知反馈指示所述终端回复同意被感知或所述终端未回复。
  33. 如权利要求31或32所述的方法，其特征在于，所述方法还包括：
    所述第二通信装置从所述数据管理功能网元获取所述终端签约的感知权限。
  34. 如权利要求29至33中任一项所述的方法，其特征在于，所述数据管理功能网元确定所述目标业务要求，包括：
    所述数据管理功能网元根据映射关系确定所述目标业务要求，所述映射关系包括至少一种业务要求与如下一项或多项的至少一种组合的对应关系：所述终端签约的感知权限、所述终端的感知通知反馈、所述终端的位置、所述感知请求的时间信息或所述业务要求请求的时间信息。
  35. 一种通信系统，其特征在于，包括第一通信装置、第二通信装置或数据管理功能网元中的一项或多项；
    其中，所述第二通信装置用于执行如权利要求1至15中任一项所述的感知方法，所述数据管理网元用于执行如权利要求16至24中任一项所述的感知方法，所述第一通信装置用于执行如权利要求25至27中任一项所述的感知方法。
  36. 一种通信装置，其特征在于，包括一种或多种功能单元，用于实现如权利要求1至27中任一项所述的方法。
  37. 一种通信装置，其特征在于，包括处理器，所述处理器用于执行程序代码，以使得所述通信装置实现如权利要求1至27中任一项所述的方法。
  38. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，使得如权利要求1至27中任一项所述的方法被执行。
  39. 一种计算机程序产品，其特征在于，包括计算机程序，当所述计算机程序被运行时，使得如权利要求1至27中任一项所述的方法被执行。
PCT/CN2025/071749 2024-01-12 2025-01-10 感知方法、通信装置和系统 Pending WO2025149036A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410053504.3A CN120321634A (zh) 2024-01-12 2024-01-12 感知方法、通信装置和系统
CN202410053504.3 2024-01-12

Publications (1)

Publication Number Publication Date
WO2025149036A1 true WO2025149036A1 (zh) 2025-07-17

Family

ID=96333315

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/071749 Pending WO2025149036A1 (zh) 2024-01-12 2025-01-10 感知方法、通信装置和系统

Country Status (2)

Country Link
CN (1) CN120321634A (zh)
WO (1) WO2025149036A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115278638A (zh) * 2022-07-22 2022-11-01 中国联合网络通信集团有限公司 感知数据获取方法、装置、设备及存储介质
CN115706955A (zh) * 2021-08-04 2023-02-17 华为技术有限公司 提供通信感知业务的方法、通信装置和系统
CN115734200A (zh) * 2021-09-01 2023-03-03 华为技术有限公司 对终端设备进行感知的方法和通信装置
CN115866635A (zh) * 2021-09-24 2023-03-28 维沃移动通信有限公司 感知业务处理方法、终端及网络侧设备
WO2023225863A1 (zh) * 2022-05-24 2023-11-30 北京小米移动软件有限公司 一种提供感知服务的方法、装置、设备以及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115706955A (zh) * 2021-08-04 2023-02-17 华为技术有限公司 提供通信感知业务的方法、通信装置和系统
CN115734200A (zh) * 2021-09-01 2023-03-03 华为技术有限公司 对终端设备进行感知的方法和通信装置
CN115866635A (zh) * 2021-09-24 2023-03-28 维沃移动通信有限公司 感知业务处理方法、终端及网络侧设备
WO2023225863A1 (zh) * 2022-05-24 2023-11-30 北京小米移动软件有限公司 一种提供感知服务的方法、装置、设备以及存储介质
CN115278638A (zh) * 2022-07-22 2022-11-01 中国联合网络通信集团有限公司 感知数据获取方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN120321634A (zh) 2025-07-15

Similar Documents

Publication Publication Date Title
US12089038B2 (en) Method and apparatus for performing authorization for unmanned aerial system service in wireless communication system
KR102436652B1 (ko) 5g 시스템에서 차량 통신 서비스 제공 방법
US9154501B2 (en) Machine-to-machine communications privacy protection method and system, machine-to-machine communications service management entity, and related device
WO2023061412A1 (zh) 一种传输信息的方法、装置以及系统
US20250175530A1 (en) Communication sensing method and apparatus
WO2022259830A1 (en) Method of user equipment (ue) and user equipment (ue)
US20230397155A1 (en) Height-Based Management of Wireless Device
US20230136425A1 (en) N14 interface support indicator for service continuity
US12477333B2 (en) Communication method and device for supporting authentication of unmanned aerial vehicle in wireless communication system
KR20230138387A (ko) 로컬화된 서비스에 관련된 통신
WO2023065778A1 (zh) 中继通信的方法和装置
US20230413225A1 (en) Change of Height of Wireless Device
US20250056231A1 (en) Ranging Service
WO2025124528A1 (zh) 一种通信方法及通信装置
WO2025149036A1 (zh) 感知方法、通信装置和系统
CN118785136A (zh) 通信方法、通信装置及通信系统
CN116866844A (zh) 通信方法及装置
WO2025148848A1 (zh) 通信方法及相关装置、系统
KR20220020115A (ko) 이동통신 시스템에서 사용자 평면을 이용한 무인항공기의 인증을 지원하는 방법 및 장치
US20250106801A1 (en) Registration and selection of user equipment for wireless network sensing services
EP4668812A1 (en) Communication method and communication apparatus
WO2025167841A1 (zh) 一种通信方法及装置
US20250106710A1 (en) Service continuity of bistatic ue-assisted sensing services
WO2025251874A1 (zh) 一种感知通信方法、装置及系统
CN120730306A (zh) 一种鉴权方法及通信装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25738563

Country of ref document: EP

Kind code of ref document: A1