Patent Description:
<CIT> relates to vehicle route generation using road lane line quality. <NPL> introduces an edge information system for intelligent IoV, including edge caching, edge computing, and edge AI.

Various embodiments will be described in detail with reference to the accompanying drawings. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the claims.

The term "mobile device" is used herein to refer to any one or all of wireless router devices, wireless appliances, cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, ultrabooks, palmtop computers, wireless electronic mail receivers, multimedia Internet-enabled cellular telephones, medical devices and equipment, biometric sensors/devices, wearable devices including smart watches, smart clothing, smart glasses, smart wrist bands, smart jewelry (e.g., smart rings, smart bracelets, etc.), entertainment devices (e.g., wireless gaming controllers, music and video players, satellite radios, etc.), wireless-network enabled Internet of Things (IoT) devices including smart meters/sensors, industrial manufacturing equipment, large and small machinery and appliances for home or enterprise use, wireless communication elements within autonomous and semiautonomous vehicles, mobile devices affixed to or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices that include a memory, wireless communication components and a programmable processor.

The term "system in a package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computational units, cores and/or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, the SIP may include one or more multichip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unifying substrate. A SIP may also include multiple independent SOCs coupled together via high speed communication circuitry and packaged in close proximity, such as on a single motherboard or in a single mobile device. The proximity of the SOCs facilitates high speed communications and the sharing of memory and resources.

The term "multicore processor" may be used herein to refer to a single integrated circuit (IC) chip or chip package that contains two or more independent processing cores (e.g., CPU core, Internet protocol (IP) core, graphics processor unit (GPU) core, etc.) configured to read and execute program instructions. A SOC may include multiple multicore processors, and each processor in an SOC may be referred to as a core. The term "multiprocessor" may be used herein to refer to a system or device that includes two or more processing units configured to read and execute program instructions.

As used in this application, the terms "component," "system," "unit," "module," and the like include a computer-related entity, such as, but not limited to, hardware, firmware, a combination of hardware and software, software, or software in execution, which are configured to perform particular operations or functions. For example, a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a communication device and the communication device may be referred to as a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one processor or core and/or distributed between two or more processors or cores. In addition, these components may execute from various non-transitory computer readable media having various instructions and/or data structures stored thereon. Components may communicate by way of local and/or remote processes, function or procedure calls, electronic signals, data packets, memory read/writes, and other known computer, processor, and/or process related communication methodologies.

Conventionally, a vehicle or mobile device constructs an LDM using information obtained from one or more sensors (e.g., cameras, radar, LIDAR, etc.), from one or more other mobile devices or vehicles, and/or from remote data sources and network elements such as cloud-based servers. Processing this information and rendering the LDM data into a useable or presentable form, such as a digital map, requires numerous processor intensive operations.

The information used by a vehicle or mobile device is typically limited to data that can be stored in memory (e.g., static maps) and data from onboard sensors. LDM data received from onboard sensors and from other mobile devices is limited by the sensitivity, field of view and perceptual limits of each sensor. LDM data received from distant network elements typically does not include very recent changes in the environment near the vehicle of mobile device, and so may not reflect highly dynamic environmental conditions (e.g., road closures, construction, accidents, etc.).

LDM data may be structured in a variety of types reflecting a degree to which such information may change dynamically. For example, LDM data may be classified (for example, in relevant European Telecommunications Standards Institute (ETSI), standards) as: Type <NUM> for permanent static information, such as the locations of roads and geographic features; Type <NUM> for transient static information, such as speed limits; Type <NUM> for transient dynamic information, such as weather and traffic information; and Type <NUM> for highly dynamic information, such as locations of other vehicles in motion, pedestrians, parked vehicles, the state of traffic signals, and other highly transient conditions. In particular, LDM data from remote network elements does not include highly dynamic information (e.g., Type <NUM> information), because the collection, storage, organization and distribution of detailed transient conditions can be prohibitively complex and expensive. Additionally, vehicles and other mobile devices that rely on LDM data do not benefit from receiving information about conditions and events far away and therefore not relevant to operations, such as navigation. Thus, transmitting LDM data from remote data sources may unnecessarily increase the computational burden on the mobile device by requiring processing of irrelevant data.

Many of these shortcomings may be addressed by employing Edge computing resources to assemble, process and distribute LDM data to nearby vehicles/mobile devices. Edge computing is a distributed computing paradigm that positions network computing devices and data storage closer to devices such as mobile devices. Edge computing may be deployed to supplement processing capabilities of mobile devices by performing some processing tasks within the Edge computing devices and transmitting processed results to mobile devices. Edge computing systems may improve response times and save bandwidth as compared to more conventional cloud-based processing that is performed at more distant network locations from mobile devices.

Various embodiments provide methods and computing devices configured to gather, assemble and generate LDM data at an Edge computing device, and communicate the processed LDM data to nearby vehicles and mobile devices. Some embodiments leverage the greater computing power of Edge computing resources and the relative proximity of the Edge computing resources to vehicles and mobile devices to provide processed LDM data that includes highly dynamic information that is beyond the range of sensors onboard vehicles and mobile devices, but that is relevant to each vehicle and mobile device.

In various embodiments, an Edge computing device may receive new or updated (referred to as "first") LDM data for a service area of the Edge computing device. In some embodiments, the Edge computing device may receive the first LDM data from one or more data sources other than vehicles and mobile devices, such as other vehicles and mobile devices, roadside units (RSUs), data sources that may transmit Cooperative Awareness Message (CAM) messages or Decentralized Environmental Notification Message (DENM) messages, and a variety of Internet- or cloud-based resources. In some embodiments, the Edge computing device may receive the first LDM data via an Edge network interface. In some embodiments, the received first LDM data may be Type <NUM> information, or "highly dynamic" information, that reflects highly transient conditions. In some embodiments, the received LDM data may be obtained from a sensor or another information source within a threshold amount of time, such as two seconds, one second, <NUM> milliseconds, or another suitable threshold or window of time. In some embodiments, the first LDM data may include data gathered by sensors of vehicles and mobile devices and transmitted to the Edge computing device, such as sensor data, image data, audio data, or vehicle/device operating state data. In such embodiments, the Edge computing device may determine information received from vehicles and mobile devices that should be integrated into the LDM data model.

In some embodiments, the LDM data model represents an aggregation of LDM data for the service area of the Edge computing device. In some embodiments, the Edge computing device may determine second LDM data of the LDM data model that is relevant to particular vehicles and mobile devices, and may provide that determined second LDM data to the vehicles and mobile devices. In some embodiments, the LDM data that the Edge computing device determines is relevant to particular vehicles and mobile devices (i.e., the second LDM data) may be highly dynamic LDM information (e.g., as such information is defined in relevant ETSI standards).

In some embodiments, a mobile device may be a computing device in a vehicle, such as a navigation unit or vehicle control system of an autonomous vehicle or semi-autonomous vehicle. In some embodiments, providing the determined second LDM data to vehicles and mobile devices may include generating a digital map encompassing an area within a predetermined distance of each vehicle, and transmitting the generated, vehicle-specific digital map to the vehicle. In such embodiments, the digital map may be generated and transmitted in a format suitable for use by the vehicle computing device for autonomous navigation.

In some embodiments, the Edge computing device may receive a registration message from vehicles and mobile devices. The registration message may register a vehicle or mobile device to receive LDM data as a service from the Edge application server. In some embodiments, the Edge computing device may receive from the mobile device information that is included in or with the registration message, such as information regarding the location of the mobile device, information regarding a planned route of the mobile device, information about kinematics of the mobile device, and other information from the mobile device. In some embodiments, the Edge computing device may use any of such information to determine second LDM data that is relevant to each of the vehicles and mobile devices. In various embodiments, the Edge computing device may provide the second LDM data to each of the vehicles and mobile devices over an Edge network interface.

Various embodiments improve the operation of vehicles and mobile devices by leveraging Edge computing resources to aggregate and process LDM data local to a surface area of the Edge computing device and to provide that aggregated and processed LDM data to vehicles and mobile devices. Various embodiments improve the operation of vehicles and mobile devices by leveraging Edge computing resources to determine LDM data that is relevant to particular vehicles and mobile devices and provide that relevant LDM data to the corresponding vehicle or mobile device. Various embodiments may provide LDM data to vehicles and mobile devices that may otherwise be unavailable to the vehicles and mobile devices, thereby improving the accuracy of applications and systems that use the LDM data. Various embodiments reduce a processing burden on vehicles and mobile devices associated with processing the LDM data, which may be highly resource intensive.

<FIG> illustrates an example of a communications system <NUM> that is suitable for implementing various embodiments. The communications system <NUM> may be an <NUM> NR network, or any other suitable communication network (e.g., <NUM> LTE, <NUM>, etc.).

The communications system <NUM> may include a heterogeneous network architecture that includes a core network <NUM> and a variety of mobile devices (illustrated as mobile devices 120a-120e in <FIG>). The communications system <NUM> may include an Edge network <NUM> provide network computing resources in proximity to the mobile devices. The communications system <NUM> may also include a number of base stations (illustrated as the BS 110a, the BS 110b, the BS 110c, and the BS 110d) and other network entities. A base station is an entity that communicates with mobile devices (mobile devices), and also may be referred to as an NodeB, a Node B, an LTE evolved nodeB (eNB), an access point (AP), a radio head, a transmit receive point (TRP), a New Radio base station (NR BS), a <NUM> NodeB (NB), a Next Generation NodeB (gNB), or the like. Each base station may provide communication coverage for a particular geographic area. In 3GPP, the term "cell" can refer to a coverage area of a base station, a base station subsystem serving this coverage area, or a combination thereof, depending on the context in which the term is used.

A base station 110a-<NUM>10d may provide communication coverage for a macro cell, a pico cell, a femto cell, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographic area (for example, several kilometers in radius) and may allow unrestricted access by mobile devices with service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by mobile devices with service subscription. A femto cell may cover a relatively small geographic area (for example, a home) and may allow restricted access by mobile devices having association with the femto cell (for example, mobile devices in a closed subscriber group (CSG)). A base station for a macro cell may be referred to as a macro BS. A base station for a pico cell may be referred to as a pico BS. A base station for a femto cell may be referred to as a femto BS or a home BS. In the example illustrated in <FIG>, a base station 110a may be a macro BS for a macro cell 102a, a base station 110b may be a pico BS for a pico cell 102b, and a base station 110c may be a femto BS for a femto cell 102c. A base station 110a-110d may support one or multiple (for example, three) cells.

In some examples, a cell may not be stationary, and the geographic area of the cell may move according to the location of a mobile base station. In some examples, the base stations 110a-110d may be interconnected to one another as well as to one or more other base stations or network nodes (not illustrated) in the communications system <NUM> through various types of backhaul interfaces, such as a direct physical connection, a virtual network, or a combination thereof using any suitable transport network.

The base station 110a-110d may communicate with the core network <NUM> over a wired or wireless communication link <NUM>. The mobile device 120a-120e may communicate with the base station 110a-110d over a wireless communication link <NUM>.

The communications system <NUM> also may include relay stations (e.g., relay BS 110d). A relay station is an entity that can receive a transmission of data from an upstream station (for example, a base station or a mobile device) and send a transmission of the data to a downstream station (for example, a mobile device or a base station). A relay station also may be a mobile device that can relay transmissions for other mobile devices. In the example illustrated in <FIG>, a relay station 110d may communicate with macro the base station 110a and the mobile device 120d in order to facilitate communication between the base station 110a and the mobile device 120d. A relay station also may be referred to as a relay base station, a relay base station, a relay, etc..

The mobile devices 120a, 120b, 120c may be dispersed throughout communications system <NUM>, and each mobile device may be stationary or mobile. A mobile device also may be referred to as an access terminal, a terminal, a mobile station, a subscriber unit, a station, etc..

A macro base station 110a may communicate with the communication network <NUM> over a wired or wireless communication link <NUM>. The mobile devices 120a, 120b, 120c may communicate with a base station 110a-110d over a wireless communication link <NUM>.

The wireless communication links <NUM>, <NUM> may include a plurality of carrier signals, frequencies, or frequency bands, each of which may include a plurality of logical channels. The wireless communication links <NUM> and <NUM> may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in a wireless communication link include 3GPP LTE, <NUM>, <NUM>, <NUM> (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile telephony communication technologies cellular RATs. Further examples of RATs that may be used in one or more of the various wireless communication links <NUM>, <NUM> within the communication system <NUM> include medium range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, and relatively short range RATs such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE).

For example, the spacing of the subcarriers may be <NUM> and the minimum resource allocation (called a "resource block") may be <NUM> subcarriers (or <NUM>). Consequently, the nominal Fast File Transfer (FFT) size may be equal to <NUM>, <NUM>, <NUM>, <NUM> or <NUM> for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM> megahertz (MHz), respectively. For example, a subband may cover <NUM> (i.e., <NUM> resource blocks), and there may be <NUM>, <NUM>, <NUM>, <NUM> or <NUM> subbands for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM>, respectively.

While descriptions of some embodiments may use terminology and examples associated with LTE technologies, various embodiments may be applicable to other wireless communications systems, such as a new radio (NR) or <NUM> network. NR may utilize OFDM with a cyclic prefix (CP) on the uplink (UL) and downlink (DL) and include support for half duplex operation using time division duplex (TDD). A single component carrier bandwidth of <NUM> may be supported. NR resource blocks may span <NUM> sub-carriers with a sub-carrier bandwidth of <NUM> over a <NUM> duration. Each radio frame may consist of <NUM> subframes with a length of <NUM>. Consequently, each subframe may have a length of <NUM>. Each subframe may indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each subframe may be dynamically switched. Each subframe may include DL/UL data as well as DL/UL control data. Multiple Input Multiple Output (MIMO) transmissions with precoding may also be supported. MIMO configurations in the DL may support up to eight transmit antennas with multi-layer DL transmissions up to eight streams and up to two streams per mobile device. Multi-layer transmissions with up to <NUM> streams per mobile device may be supported. Aggregation of multiple cells may be supported with up to eight serving cells. Alternatively, NR may support a different air interface, other than an OFDM-based air interface.

Some mobile devices may be considered machine-type communication (MTC) or evolved or enhanced machine-type communication (eMTC) mobile devices. MTC and eMTC mobile devices include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., that may communicate with a base station, another device (for example, remote device), or some other entity. A wireless node may provide, for example, connectivity for or to a network (for example, a wide area network such as Internet or a cellular network) via a wired or wireless communication link. Some mobile devices may be considered Internet-ofThings (IoT) devices or may be implemented as NB-IoT (narrowband internet of things) devices. A mobile device 120a-e may be included inside a housing that houses components of the mobile device, such as processor components, memory components, similar components, or a combination thereof.

In general, any number of communications systems and any number of wireless networks may be deployed in a given geographic area. Each communications system and wireless network may support a particular radio access technology (RAT) and may operate on one or more frequencies. A RAT also may be referred to as a radio technology, an air interface, etc. A frequency also may be referred to as a carrier, a frequency channel, etc. Each frequency may support a single RAT in a given geographic area in order to avoid interference between communications systems of different RATs.

In some implementations, two or more mobile devices 120a-e (for example, illustrated as the mobile device 120a and the mobile device 120e) may communicate directly using one or more sidelink channels <NUM> (for example, without using a base station <NUM> as an intermediary to communicate with one another). For example, the mobile devices 120a-e may communicate using peer-to-peer (P2P) communications, device-to-device (D2D) communications, a vehicle-to-everything (V2X) protocol (which may include a vehicle-to-vehicle (V2V) protocol, a vehicle-to-infrastructure (V2I) protocol, or similar protocol), a mesh network, or similar networks, or combinations thereof. In this case, the mobile device 120a-e may perform scheduling operations, resource selection operations, as well as other operations described elsewhere herein as being performed by the base station 110a.

Various embodiments may be implemented within a variety of vehicles, an example vehicle <NUM> of which is illustrated in <FIG> and <FIG>. With reference to <FIG> and <FIG>, a vehicle <NUM> may include a control unit <NUM> and a plurality of sensors <NUM>-<NUM>, including satellite geopositioning system receivers <NUM>, occupancy sensors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, tire pressure sensors <NUM>, <NUM>, cameras <NUM>, <NUM>, microphones <NUM>, <NUM>, impact sensors <NUM>, radar <NUM>, and lidar <NUM>. The plurality of sensors <NUM>-<NUM>, disposed in or on the vehicle, may be used for various purposes, such as autonomous and semi-autonomous navigation and control, crash avoidance, position determination, etc., as well to provide sensor data regarding objects and people in or on the vehicle <NUM>. The sensors <NUM>-<NUM> may include one or more of a wide variety of sensors capable of detecting a variety of information useful for navigation and collision avoidance. Each of the sensors <NUM>-<NUM> may be in wired or wireless communication with a control unit <NUM>, as well as with each other. In particular, the sensors may include one or more cameras <NUM>, <NUM> or other optical sensors or photo optic sensors. The sensors may further include other types of object detection and ranging sensors, such as radar <NUM>, lidar <NUM>, IR sensors, and ultrasonic sensors. The sensors may further include tire pressure sensors <NUM>, <NUM>, humidity sensors, temperature sensors, satellite geopositioning sensors <NUM>, control input sensors <NUM>, accelerometers, vibration sensors, gyroscopes, gravimeters, impact sensors <NUM>, force meters, stress meters, strain sensors, fluid sensors, chemical sensors, gas content analyzers, pH sensors, radiation sensors, Geiger counters, neutron detectors, biological material sensors, microphones <NUM>, <NUM>, occupancy sensors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, proximity sensors, and other sensors.

The vehicle control unit <NUM> may be configured with processor-executable instructions to perform navigation and collision avoidance operations using information received from various sensors, particularly the cameras <NUM>, <NUM>. In some embodiments, the control unit <NUM> may supplement the processing of camera images using distance and relative position (e.g., relative bearing angle) that may be obtained from radar <NUM> and/or lidar <NUM> sensors. The control unit <NUM> may further be configured to control steering, breaking and speed of the vehicle <NUM> when operating in an autonomous or semi-autonomous mode using information regarding other vehicles determined using various embodiments.

<FIG> is a component block diagram illustrating a communication system <NUM> of components and support systems suitable for implementing various embodiments. With reference to <FIG>, a vehicle <NUM> may include a control unit <NUM>, which may include various circuits and devices used to control the operation of the vehicle <NUM>. In the example illustrated in <FIG> the control unit <NUM> includes a processor 140a, memory 140b, an input module 140c, an output module 140d and a radio module 140e. The control unit <NUM> may be coupled to and configured to control drive control components 172a, navigation components 172b, and one or more sensors 172c of the vehicle <NUM>. The processor 140a that may be configured with processor-executable instructions to control maneuvering, navigation, and/or other operations of the vehicle <NUM>, including operations of various embodiments. The processor 140a may be coupled to the memory 140b.

The radio module 140e may be configured for wireless communication. The radio module 140e may exchange signals (e.g., command signals for controlling maneuvering, signals from navigation facilities, etc.) via the communication link <NUM> with a network transceiver (e.g., the base station <NUM>), and may provide the signals to the processor 140a and/or the navigation unit 172b. In some embodiments, the radio module 140e may enable the vehicle <NUM> to communicate with a wireless communication device <NUM> through the wireless communication link <NUM>. The wireless communication link <NUM> may be a bidirectional or unidirectional communication link, and may use one or more communication protocols, as described.

The input module 140c may receive sensor data from one or more vehicle sensors 172c as well as electronic signals from other components, including the drive control components 172a and the navigation components 172b. The output module 140d may communicate with or activate various components of the vehicle <NUM>, including the drive control components 172a, the navigation components 172b, and the sensor(s) 172c.

The control unit <NUM> may be coupled to the drive control components 172a to control physical elements of the vehicle <NUM> related to maneuvering and navigation of the vehicle, such as the engine, motors, throttles, steering elements, flight control elements, braking or deceleration elements, and the like. The drive control components 172a may also include components that control other devices of the vehicle, including environmental controls (e.g., air conditioning and heating), external and/or interior lighting, interior and/or exterior informational displays (which may include a display screen or other devices to display information), safety devices (e.g., haptic devices, audible alarms, etc.), and other similar devices.

The control unit <NUM> may be coupled to the navigation components 172b, and may receive data from the navigation components 172b and be configured to use such data to determine the present position and orientation of the vehicle <NUM>, as well as an appropriate course toward a destination. The navigation components 172b may include or be coupled to a global navigation satellite system (GNSS) receiver system (e.g., one or more Global Positioning System (GPS) receivers) enabling the vehicle <NUM> to determine its current position using GNSS signals. Alternatively, or in addition, the navigation components 172b may include radio navigation receivers for receiving navigation beacons or other signals from radio nodes, such as Wi-Fi access points, cellular network sites, radio station, remote computing devices, other vehicles, etc. Through control of the drive control elements 172a, the processor 140a may control the vehicle <NUM> to navigate and maneuver. The processor 140a and/or the navigation components 172b may be configured to communicate with a network element such as a server in a communication network (e.g., the core network <NUM>) via the wireless communication link <NUM> to receive commands to control maneuvering, receive data useful in navigation, provide real-time position reports, and assess other data.

The control unit <NUM> may be coupled to one or more sensors 172c. The sensor(s) 172c may include the sensors <NUM>-<NUM> as described, and may the configured to provide a variety of data to the processor 140a.

While the control unit <NUM> is described as including separate components, in some embodiments some or all of the components (e.g., the processor 140a, the memory 140b, the input module 140c, the output module 140d, and the radio module 140e) may be integrated in a single device or module, such as a system-on-chip (SOC) processing device. Such an SOC processing device may be configured for use in vehicles and be configured, such as with processor-executable instructions executing in the processor 140a, to perform operations of navigation and collision avoidance using LDM data when installed in a vehicle.

<FIG> is a system block diagram illustrating aspects of the Edge network <NUM> suitable for implementing various embodiments. In some embodiments, each vehicle <NUM> (or any other mobile device) may be configured with an application client 101a and an Edge enabler client 101b. In some embodiments, the application client 101a and an Edge enabler client 101b may communicate with an Edge Enabler Server (EAS) 184a-184c via a wireless communication link. Each of the Edge Enabler Servers 184a-184c may communicate with an Edge Enabler Server <NUM> via a wired or wireless communication link. The Edge Enabler Server <NUM> may communicate with an LDM database <NUM>. Each of the Edge Enabler Servers 184a-184c may also communicate with the LDM database <NUM> directly. Aspects of the various wired and wireless communication links are described above with respect to <FIG>. In some embodiments, each EAS 184a-184c and <NUM> may execute on one or more computing devices, such as network servers or another suitable computing device.

In various embodiments, the LDM database <NUM> may store LDM data and/or an LDM data model. The EAS <NUM> may maintain, update, add, and delete information from the LDM database <NUM>. In some embodiments, the EAS <NUM> may receive new or updated LDM data from a vehicle <NUM> via an EAS 184a-184c for an Edge service area and may integrate the LDM data into the LDM data model. In some embodiments, the EAS <NUM> may execute one or more authentication or security functions to verify the LDM data before the data is included or integrated into the LDM data model in the LDM database <NUM>.

In some embodiments, an EAS 184a-184c may execute on a computing device for each vehicle <NUM>. In some embodiments, the EAS 184a-184c may determine a subset of LDM data to provide to the associated vehicle <NUM>, and then provide the determined subset of LDM data to the vehicle <NUM>. In some embodiments, the EAS 184a-184c may query the EAS <NUM> and/or the LDM database <NUM> for suitable LDM information for the vehicle <NUM>. In some embodiments, the EAS 184a-184c associated with a vehicle <NUM> may generate a vehicle state representation for the associated vehicle <NUM>. In some embodiments, the vehicle state representation may include information about the associated vehicle such as a location, a direction of motion, a velocity, an occupancy, a status (e.g., an operational status, such as "on", "parked", "in motion", etc.), size, dimension, and/or volume information about the vehicle, and other vehicle-descriptive information. Some embodiments may also be applied to other mobile devices (e.g., beyond vehicles), for which the EAS 184a-184c may determine and maintain an applicable state representation (e.g., including parameters applicable to the particular mobile device). In some embodiments, the EAS 184a-184c may use the vehicle state representation to determine relevant LDM information to provide to the vehicle <NUM>. In some embodiments, the EAS 184a-184c may provide the vehicle state representation to the EAS <NUM> to enable the EAS <NUM> to determine relevant LDM information to provide to the vehicle <NUM>. In some embodiments, the vehicle state representation may also include a current LDM subset stored by or used by the associated vehicle <NUM>.

<FIG> is a component block diagram illustrating components of an example vehicle management system <NUM>. The vehicle management system <NUM> may include various subsystems, communication elements, computational elements, computing devices or units which may be utilized within a vehicle <NUM>. With reference to <FIG>, the various computational elements, computing devices or units within vehicle management system <NUM> may be implemented within a system of interconnected computing devices (i.e., subsystems), that communicate data and commands to each other (e.g., indicated by the arrows in <FIG>). In some implementations, the various computational elements, computing devices or units within vehicle management system <NUM> may be implemented within a single computing device, such as separate threads, processes, algorithms or computational elements. Therefore, each subsystem/computational element illustrated in <FIG> is also generally referred to herein as "layer" within a computational "stack" that constitutes the vehicle management system <NUM>. However, the use of the terms layer and stack in describing various embodiments are not intended to imply or require that the corresponding functionality is implemented within a single autonomous (or semi-autonomous) vehicle management system computing device, although that is a potential implementation embodiment. Rather the use of the term "layer" is intended to encompass subsystems with independent processors, computational elements (e.g., threads, algorithms, subroutines, etc.) running in one or more computing devices, and combinations of subsystems and computational elements.

The vehicle management system stack may include a radar perception layer <NUM>, a camera perception layer <NUM>, a positioning engine layer <NUM>, a map fusion and arbitration layer <NUM>, a route planning layer <NUM>, sensor fusion and road world model (RWM) management layer <NUM>, motion planning and control layer <NUM>, and behavioral planning and prediction layer <NUM>. The layers <NUM>-<NUM> are merely examples of some layers in one example configuration of the vehicle management system stack <NUM>. In other configurations, other layers may be included, such as additional layers for other perception sensors (e.g., LIDAR perception layer, etc.), additional layers for planning and/or control, additional layers for modeling, etc., and/or certain of the layers <NUM>-<NUM> may be excluded from the vehicle management system stack <NUM>. Each of the layers <NUM>-<NUM> may exchange data, computational results and commands as illustrated by the arrows in <FIG>. Further, the vehicle management system stack <NUM> may receive and process data from sensors (e.g., radar, lidar, cameras, inertial measurement units (IMU) etc.), navigation systems (e.g., GPS receivers, IMUs, etc.), vehicle networks (e.g., Controller Area Network (CAN) bus), and databases in memory (e.g., digital map data). The vehicle management system stack <NUM> may output vehicle control commands or signals to the drive by wire (DBW) system/control unit <NUM>, which is a system, subsystem or computing device that interfaces directly with vehicle steering, throttle and brake controls. The configuration of the vehicle management system stack <NUM> and DBW system/control unit <NUM> illustrated in <FIG> is merely an example configuration and other configurations of a vehicle management system and other vehicle components may be used. As an example, the configuration of the vehicle management system stack <NUM> and DBW system/control unit <NUM> illustrated in <FIG> may be used in a vehicle configured for autonomous or semi-autonomous operation while a different configuration may be used in a non-autonomous vehicle.

The radar perception layer <NUM> may receive data from one or more detection and ranging sensors, such as radar (e.g., <NUM>) and/or lidar (e.g., <NUM>), and process the data to recognize and determine locations of other vehicles and objects within a vicinity of the vehicle <NUM>. The radar perception layer <NUM> may include use of neural network processing and artificial intelligence methods to recognize objects and vehicles, and pass such information on to the sensor fusion and RWM management layer <NUM>.

The camera perception layer <NUM> may receive data from one or more cameras, such as cameras (e.g., <NUM>, <NUM>), and process the data to recognize and determine locations of other vehicles and objects within a vicinity of the vehicle <NUM>. The camera perception layer <NUM> may include use of neural network processing and artificial intelligence methods to recognize objects and vehicles, and pass such information on to the sensor fusion and RWM management layer <NUM>.

The positioning engine layer <NUM> may receive data from various sensors and process the data to determine a position of the vehicle <NUM>. The various sensors may include, but is not limited to, GPS sensor, an IMU, and/or other sensors connected via a CAN bus. The positioning engine layer <NUM> may also utilize inputs from one or more cameras, such as cameras (e.g., <NUM>, <NUM>) and/or any other available sensor, such as radars, LIDARs, etc..

The vehicle management system <NUM> may include or be coupled to a vehicle wireless communication subsystem <NUM>. The wireless communication subsystem <NUM> may be configured to communicate with other vehicle computing devices and highway communication systems, such as via vehicle-to-vehicle (V2V) communication links and/or to remote information sources, such as cloud-based resources, via cellular wireless communication systems, such as <NUM> networks. In various embodiments, the wireless communication subsystem <NUM> may communicate with Edge computing devices via wireless communication links to receive LDM data.

The map fusion and arbitration layer <NUM> may access LDM data received from Edge computing devices and receive output received from the positioning engine layer <NUM> and process the data to further determine the position of the vehicle <NUM> within the map, such as location within a lane of traffic, position within a street map, etc. LDM data may be stored in a memory (e.g., memory <NUM>). For example, the map fusion and arbitration layer <NUM> may convert latitude and longitude information from GPS into locations within a surface map of roads contained in the LDM data. GPS position fixes include errors, so the map fusion and arbitration layer <NUM> may function to determine a best guess location of the vehicle within a roadway based upon an arbitration between the GPS coordinates and the LDM data. For example, while GPS coordinates may place the vehicle near the middle of a two-lane road in the LDM data, the map fusion and arbitration layer <NUM> may determine from the direction of travel that the vehicle is most likely aligned with the travel lane consistent with the direction of travel. The map fusion and arbitration layer <NUM> may pass map-based location information to the sensor fusion and RWM management layer <NUM>.

The route planning layer <NUM> may utilize LDM data, as well as inputs from an operator or dispatcher to plan a route to be followed by the vehicle <NUM> to a particular destination. The route planning layer <NUM> may pass map-based location information to the sensor fusion and RWM management layer <NUM>. However, the use of a prior map by other layers, such as the sensor fusion and RWM management layer <NUM>, etc., is not required. For example, other stacks may operate and/or control the vehicle based on perceptual data alone without a provided map, constructing lanes, boundaries, and the notion of a local map as perceptual data is received.

The sensor fusion and RWM management layer <NUM> may receive data and outputs produced by the radar perception layer <NUM>, camera perception layer <NUM>, map fusion and arbitration layer <NUM>, and route planning layer <NUM>, and use some or all of such inputs to estimate or refine the location and state of the vehicle <NUM> in relation to the road, other vehicles on the road, and other objects within a vicinity of the vehicle <NUM>. For example, the sensor fusion and RWM management layer <NUM> may combine imagery data from the camera perception layer <NUM> with arbitrated map location information from the map fusion and arbitration layer <NUM> to refine the determined position of the vehicle within a lane of traffic. As another example, the sensor fusion and RWM management layer <NUM> may combine object recognition and imagery data from the camera perception layer <NUM> with object detection and ranging data from the radar perception layer <NUM> to determine and refine the relative position of other vehicles and objects in the vicinity of the vehicle. As another example, the sensor fusion and RWM management layer <NUM> may receive information from vehicle-to-vehicle (V2V) communications (such as via the CAN bus) regarding other vehicle positions and directions of travel, and combine that information with information from the radar perception layer <NUM> and the camera perception layer <NUM> to refine the locations and motions of other vehicles. The sensor fusion and RWM management layer <NUM> may output refined location and state information of the vehicle <NUM>, as well as refined location and state information of other vehicles and objects in the vicinity of the vehicle, to the motion planning and control layer <NUM> and/or the behavior planning and prediction layer <NUM>.

As a further example, the sensor fusion and RWM management layer <NUM> may use dynamic traffic control instructions directing the vehicle <NUM> to change speed, lane, direction of travel, or other navigational element(s), and combine that information with other received information to determine refined location and state information. The sensor fusion and RWM management layer <NUM> may output the refined location and state information of the vehicle <NUM>, as well as refined location and state information of other vehicles and objects in the vicinity of the vehicle <NUM>, to the motion planning and control layer <NUM>, the behavior planning and prediction layer <NUM> and/or devices remote from the vehicle <NUM>, such as a data server, other vehicles, etc., via wireless communications, such as through C-V2X connections, other wireless connections, etc..

As a still further example, the sensor fusion and RWM management layer <NUM> may monitor perception data from various sensors, such as perception data from a radar perception layer <NUM>, camera perception layer <NUM>, other perception layer, etc., and/or data from one or more sensors themselves to analyze conditions in the vehicle sensor data. The sensor fusion and RWM management layer <NUM> may be configured to detect conditions in the sensor data, such as sensor measurements being at, above, or below a threshold, certain types of sensor measurements occurring, etc., and may output the sensor data as part of the refined location and state information of the vehicle <NUM> provided to the behavior planning and prediction layer <NUM> and/or devices remote from the vehicle <NUM>, such as a data server, other vehicles, etc., via wireless communications, such as through C-V2X connections, other wireless connections, etc..

The refined location and state information may include vehicle descriptors associated with the vehicle and the vehicle owner and/or operator, such as: vehicle specifications (e.g., size, weight, color, on board sensor types, etc.); vehicle position, speed, acceleration, direction of travel, attitude, orientation, destination, fuel/power level(s), and other state information; vehicle emergency status (e.g., is the vehicle an emergency vehicle or private individual in an emergency); vehicle restrictions (e.g., heavy/wide load, turning restrictions, high occupancy vehicle (HOV) authorization, etc.); capabilities (e.g., all-wheel drive, four-wheel drive, snow tires, chains, connection types supported, on board sensor operating statuses, on board sensor resolution levels, etc.) of the vehicle; equipment problems (e.g., low tire pressure, weak breaks, sensor outages, etc.); owner/operator travel preferences (e.g., preferred lane, roads, routes, and/or destinations, preference to avoid tolls or highways, preference for the fastest route, etc.); permissions to provide sensor data to a data agency server (e.g., <NUM>); and/or owner/operator identification information.

The behavioral planning and prediction layer <NUM> of the autonomous vehicle system stack <NUM> may use the refined location and state information of the vehicle <NUM> and location and state information of other vehicles and objects output from the sensor fusion and RWM management layer <NUM> to predict future behaviors of other vehicles and/or objects. For example, the behavioral planning and prediction layer <NUM> may use such information to predict future relative positions of other vehicles in the vicinity of the vehicle based on own vehicle position and velocity and other vehicle positions and velocity. Such predictions may take into account information from the LDM data and route planning to anticipate changes in relative vehicle positions as host and other vehicles follow the roadway. The behavioral planning and prediction layer <NUM> may output other vehicle and object behavior and location predictions to the motion planning and control layer <NUM>. Additionally, the behavior planning and prediction layer <NUM> may use object behavior in combination with location predictions to plan and generate control signals for controlling the motion of the vehicle <NUM>. For example, based on route planning information, refined location in the roadway information, and relative locations and motions of other vehicles, the behavior planning and prediction layer <NUM> may determine that the vehicle <NUM> needs to change lanes and accelerate, such as to maintain or achieve minimum spacing from other vehicles, and/or prepare for a turn or exit. As a result, the behavior planning and prediction layer <NUM> may calculate or otherwise determine a steering angle for the wheels and a change to the throttle setting to be commanded to the motion planning and control layer <NUM> and DBW system/control unit <NUM> along with such various parameters necessary to effectuate such a lane change and acceleration. One such parameter may be a computed steering wheel command angle.

The motion planning and control layer <NUM> may receive data and information outputs from the sensor fusion and RWM management layer <NUM> and other vehicle and object behavior as well as location predictions from the behavior planning and prediction layer <NUM>, and use this information to plan and generate control signals for controlling the motion of the vehicle <NUM> and to verify that such control signals meet safety requirements for the vehicle <NUM>. For example, based on route planning information, refined location in the roadway information, and relative locations and motions of other vehicles, the motion planning and control layer <NUM> may verify and pass various control commands or instructions to the DBW system/control unit <NUM>.

The DBW system/control unit <NUM> may receive the commands or instructions from the motion planning and control layer <NUM> and translate such information into mechanical control signals for controlling wheel angle, brake and throttle of the vehicle <NUM>. For example, DBW system/control unit <NUM> may respond to the computed steering wheel command angle by sending corresponding control signals to the steering wheel controller.

In various embodiments, the wireless communication subsystem <NUM> may communicate with Edge computing devices via wireless communication links to transmit sensor data, position data, vehicle data and data gathered about the environment around the vehicle by onboard sensors. Such information may be used by Edge computing devices to update LDM data for relay to vehicles within the local area of each Edge computing device.

In various embodiments, the vehicle management system stack <NUM> may include functionality that performs safety checks or oversight of various commands, planning or other decisions of various layers that could impact vehicle and occupant safety. Such safety check or oversight functionality may be implemented within a dedicated layer or distributed among various layers and included as part of the functionality. In some embodiments, a variety of safety parameters may be stored in memory and the safety checks or oversight functionality may compare a determined value (e.g., relative spacing to a nearby vehicle, distance from the roadway centerline, etc.) to corresponding safety parameter(s), and issue a warning or command if the safety parameter is or will be violated. For example, a safety or oversight function in the behavior planning and prediction layer <NUM> (or in a separate layer) may determine the current or future separate distance between another vehicle (as defined by the sensor fusion and RWM management layer <NUM>) and the vehicle (e.g., based on the world model refined by the sensor fusion and RWM management layer <NUM>), compare that separation distance to a safe separation distance parameter stored in memory, and issue instructions to the motion planning and control layer <NUM> to speed up, slow down or turn if the current or predicted separation distance violates the safe separation distance parameter. As another example, safety or oversight functionality in the motion planning and control layer <NUM> (or a separate layer) may compare a determined or commanded steering wheel command angle to a safe wheel angle limit or parameter, and issue an override command and/or alarm in response to the commanded angle exceeding the safe wheel angle limit.

Some safety parameters stored in memory may be static (i.e., unchanging over time), such as maximum vehicle speed. Other safety parameters stored in memory may be dynamic in that the parameters are determined or updated continuously or periodically based on vehicle state information and/or environmental conditions. Non-limiting examples of safety parameters include maximum safe speed, maximum brake pressure, maximum acceleration, and the safe wheel angle limit, all of which may be a function of roadway and weather conditions.

<FIG> illustrates an example of subsystems, computational elements, computing devices or units within a vehicle management system <NUM>, which may be utilized within a vehicle <NUM>. With reference to <FIG>, in some embodiments, the layers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of the vehicle management system stack <NUM> may be similar to those described with reference to <FIG> and the vehicle management system stack <NUM> may operate similar to the vehicle management system stack <NUM>, except that the vehicle management system stack <NUM> may pass various data or instructions to a vehicle safety and crash avoidance system <NUM> rather than the DBW system/control unit <NUM>. For example, the configuration of the vehicle management system stack <NUM> and the vehicle safety and crash avoidance system <NUM> illustrated in <FIG> may be used in a non-autonomous vehicle.

In various embodiments, the behavioral planning and prediction layer <NUM> and/or sensor fusion and RWM management layer <NUM> may output data to the vehicle safety and crash avoidance system <NUM>. For example, the sensor fusion and RWM management layer <NUM> may output sensor data as part of refined location and state information of the vehicle <NUM> provided to the vehicle safety and crash avoidance system <NUM>. The vehicle safety and crash avoidance system <NUM> may use the refined location and state information of the vehicle <NUM> to make safety determinations relative to the vehicle <NUM> and/or occupants of the vehicle <NUM>. As another example, the behavioral planning and prediction layer <NUM> may output behavior models and/or predictions related to the motion of other vehicles to the vehicle safety and crash avoidance system <NUM>. The vehicle safety and crash avoidance system <NUM> may use the behavior models and/or predictions related to the motion of other vehicles to make safety determinations relative to the vehicle <NUM> and/or occupants of the vehicle <NUM>.

In various embodiments, the vehicle safety and crash avoidance system <NUM> may include functionality that performs safety checks or oversight of various commands, planning, or other decisions of various layers, as well as human driver actions, that could impact vehicle and occupant safety. In some embodiments, a variety of safety parameters may be stored in memory and the vehicle safety and crash avoidance system <NUM> may compare a determined value (e.g., relative spacing to a nearby vehicle, distance from the roadway centerline, etc.) to corresponding safety parameter(s), and issue a warning or command if the safety parameter is or will be violated. For example, a vehicle safety and crash avoidance system <NUM> may determine the current or future separate distance between another vehicle (as defined by the sensor fusion and RWM management layer <NUM>) and the vehicle (e.g., based on the world model refined by the sensor fusion and RWM management layer <NUM>), compare that separation distance to a safe separation distance parameter stored in memory, and issue instructions to a driver to speed up, slow down or turn if the current or predicted separation distance violates the safe separation distance parameter. As another example, a vehicle safety and crash avoidance system <NUM> may compare a human driver's change in steering wheel angle to a safe wheel angle limit or parameter, and issue an override command and/or alarm in response to the steering wheel angle exceeding the safe wheel angle limit.

<FIG> illustrates an example system-on-chip (SOC) architecture of a processing device SOC <NUM> suitable for implementing various embodiments in vehicles. With reference to <FIG>, the processing device SOC <NUM> may include a number of heterogeneous processors, such as a digital signal processor (DSP) <NUM>, a modem processor <NUM>, an image and object recognition processor <NUM>, a mobile display processor <NUM>, an applications processor <NUM>, and a resource and power management (RPM) processor <NUM>. The processing device SOC <NUM> may also include one or more coprocessors <NUM> (e.g., vector co-processor) connected to one or more of the heterogeneous processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Each of the processors may include one or more cores, and an independent/internal clock. Each processor/core may perform operations independent of the other processors/cores. For example, the processing device SOC <NUM> may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, the applications processor <NUM> may be the SOC's <NUM> main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. The graphics processor <NUM> may be graphics processing unit (GPU).

The processing device SOC <NUM> may include analog circuitry and custom circuitry <NUM> for managing sensor data, analog-to-digital conversions, wireless data transmissions, and for performing other specialized operations, such as processing encoded audio and video signals for rendering in a web browser. The processing device SOC <NUM> may further include system components and resources <NUM>, such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support the processors and software clients (e.g., a web browser) running on a computing device.

The processing device SOC <NUM> also include specialized circuitry for camera actuation and management (CAM) <NUM> that includes, provides, controls and/or manages the operations of one or more cameras <NUM>, <NUM> (e.g., a primary camera, webcam, 3D camera, etc.), the video display data from camera firmware, image processing, video preprocessing, video front-end (VFE), in-line JPEG, high definition video codec, etc. The CAM <NUM> may be an independent processing unit and/or include an independent or internal clock.

In some embodiments, the image and object recognition processor <NUM> may be configured with processor-executable instructions and/or specialized hardware configured to perform image processing and object recognition analyses involved in various embodiments. For example, the image and object recognition processor <NUM> may be configured to perform the operations of processing images received from cameras (e.g., <NUM>, <NUM>) via the CAM <NUM> to recognize and/or identify other vehicles, and otherwise perform functions of the camera perception layer <NUM> as described. In some embodiments, the processor <NUM> may be configured to process radar or lidar data and perform functions of the radar perception layer <NUM> as described.

The system components and resources <NUM>, analog and custom circuitry <NUM>, and/or CAM <NUM> may include circuitry to interface with peripheral devices, such as cameras <NUM>, <NUM>, radar <NUM>, lidar <NUM>, electronic displays, wireless communication devices, external memory chips, etc. The processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be interconnected to one or more memory elements <NUM>, system components and resources <NUM>, analog and custom circuitry <NUM>, CAM <NUM>, and RPM processor <NUM> via an interconnection/bus module <NUM>, which may include an array of reconfigurable logic gates and/or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as high-performance networks-on chip (NoCs).

The processing device SOC <NUM> may further include an input/output module (not illustrated) for communicating with resources external to the SOC, such as a clock <NUM> and a voltage regulator <NUM>. Resources external to the SOC (e.g., clock <NUM>, voltage regulator <NUM>) may be shared by two or more of the internal SOC processors/cores (e.g., a DSP <NUM>, a modem processor <NUM>, a graphics processor <NUM>, an applications processor <NUM>, etc.).

In some embodiments, the processing device SOC <NUM> may be included in a control unit (e.g., <NUM>) for use in a vehicle (e.g., <NUM>). The control unit may include communication links for communication with a telephone network (e.g., <NUM>), the Internet, and/or a network server (e.g., <NUM>) as described.

The processing device SOC <NUM> may also include additional hardware and/or software components that are suitable for collecting sensor data from sensors, including motion sensors (e.g., accelerometers and gyroscopes of an IMU), user interface elements (e.g., input buttons, touch screen display, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., location, direction, motion, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communications circuitry (e.g., Bluetooth®, WLAN, WiFi, etc.), and other well-known components of modem electronic devices.

<FIG> is a component block diagram illustrating a system <NUM> configured to generate local dynamic map data in accordance with various embodiments. In some embodiments, the system <NUM> may include one or more computing platforms <NUM> and/or one or more mobile devices <NUM>. With reference to <FIG>, the Edge computing device <NUM> may include a processor (e.g., <NUM>), a processing device (e.g., <NUM>), and/or a control unit (e.g., <NUM>) (variously referred to as a "processor"). The Edge computing device may be part of an Edge network <NUM> and/or a network element. The mobile device(s) <NUM> may include a processor (e.g., <NUM>), a processing device (e.g., <NUM>), and/or a control unit (e.g., <NUM>) (variously referred to as a "processor") of a vehicle (e.g., <NUM>).

The Edge computing device <NUM> may be configured by machine-executable instructions <NUM>. Machine-executable instructions <NUM> may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of an LDM data receiving module <NUM>, an LDM data integration module <NUM>, an LDM data determination module <NUM>, an LDM data providing module <NUM>, a map generating module <NUM>, a map transmittal module <NUM>, and/or other instruction modules.

The LDM data receiving module <NUM> may be configured to receive fresh LDM data for a service area of an Edge computing device. In some embodiments, the LDM data receiving module <NUM> may be configured to receive a registration message from vehicles and mobile devices. In some embodiments, the LDM data receiving module <NUM> may be configured to receive planned route information from vehicles and mobile devices. In some embodiments, the LDM data receiving module <NUM> may be configured to receive mobile device kinematics information from vehicles and mobile devices. In some embodiments, the LDM data receiving module <NUM> may be configured to receive data from vehicles and mobile devices, such as, for example, sensor data, image data, audio data, or operating state data obtained by the vehicles and mobile devices.

The LDM data integration module <NUM> may be configured to integrate the fresh LDM data into an LDM data model. In some embodiments, the LDM data model may include LDM data of the service area of the Edge computing device.

The LDM data determination module <NUM> may be configured to determine LDM data of the LDM data model that is relevant to particular vehicles and mobile devices. In some embodiments, the LDM data determination module <NUM> may be configured to determine LDM data that is relevant to a mobile device based on information included with the registration message. In some embodiments, the LDM data determination module <NUM> may be configured to determine LDM data that is relevant to particular vehicles and mobile devices based on the planned route information. In some embodiments, the LDM data determination module <NUM> may be configured to determine LDM data that is relevant to particular vehicles and mobile devices based on kinematics information. In some embodiments, the LDM data determination module <NUM> may be configured to determine from the received data information that is relevant to the LDM data. In some implementations, the LDM data determination module <NUM> may receive the fresh data via an Edge network interface.

The LDM data providing module <NUM> may be configured to provide the determined relevant LDM data to vehicles and mobile devices. In some embodiments, the determined relevant LDM data may include highly dynamic LDM information.

The map generating module <NUM> may be configured to generate a digital map encompassing an area within a predetermined distance of vehicles and mobile devices. In some embodiments, the map transmittal module <NUM> may be configured to transmit the digital map to vehicles and mobile devices. The digital map may be generated and transmitted in a format suitable for use in autonomous navigation of the vehicles.

In some implementations, the Edge computing device <NUM>, vehicles and mobile devices <NUM>, and/or external resources <NUM> may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which Edge computing device <NUM>, vehicles and mobile devices <NUM>, and/or external resources <NUM> may be operatively linked via some other communication media.

The mobile device <NUM> may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable an expert or user associated with a given vehicle or mobile device <NUM> to interface with system <NUM> and/or external resources <NUM>, and/or provide other functionality attributed herein to vehicles and mobile devices <NUM>.

The external resources <NUM> may include sources of information outside of system <NUM>, external entities participating with system <NUM>, and/or other resources. In some implementations, some or all of the functionality attributed herein to external resources <NUM> may be provided by resources included in system <NUM>.

The Edge computing device <NUM> may include an electronic storage <NUM>, one or more processors <NUM>, and/or other components. The Edge computing device <NUM> may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. The illustration of an Edge computing device <NUM> in <FIG> is not intended to be limiting. The Edge computing device <NUM> may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to Edge computing device <NUM>. For example, the Edge computing device <NUM> may be implemented by a cloud of computing platforms operating together as Edge computing device <NUM>.

The electronic storage <NUM> may comprise non-transitory storage media that electronically stores information. The electronic storage media of the electronic storage <NUM> may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with Edge computing device <NUM> and/or removable storage that is removably connectable to Edge computing device <NUM> via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage <NUM> may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage <NUM> may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). The electronic storage <NUM> may store software algorithms, information determined by processor(s) <NUM>, information received from Edge computing device <NUM>, information received from mobile device(s) <NUM>, and/or other information that enables Edge computing device <NUM> to function as described herein.

Processor(s) <NUM> may be configured to provide information processing capabilities in Edge computing device <NUM>. As such, processor(s) <NUM> may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. Although processor(s) <NUM> is shown in <FIG> as a single entity, this is for illustrative purposes only. In some implementations, processor(s) <NUM> may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s) <NUM> may represent processing functionality of a plurality of devices operating in coordination. Processor(s) <NUM> may be configured to execute modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and/or other modules. Processor(s) <NUM> may be configured to execute modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on the processor(s) <NUM>. As used herein, the term "module" may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.

It should be appreciated that although modules <NUM>-<NUM> are illustrated in <FIG> as being implemented within a single processing unit, in implementations in which the processor(s) <NUM> includes multiple processing units, one or more of the modules <NUM>-<NUM>, may be implemented remotely from the other modules. The description of the functionality provided by the different modules <NUM>-<NUM> described below is for illustrative purposes, and is not intended to be limiting, as any of the modules <NUM>-<NUM> may provide more or less functionality than is described. For example, one or more of modules <NUM>-<NUM> may be eliminated, and some or all of its functionality may be provided by other ones of the modules <NUM>-<NUM>. As another example, processor(s) <NUM> may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of the modules <NUM>-<NUM>.

<FIG> is a system block diagram illustrating an example Edge computing system <NUM> suitable for use with various embodiments. In some embodiments, Edge computing system <NUM> may include an Edge network <NUM> and a mobile device <NUM> configured to communicate via a 3GPP core network <NUM>. The Edge data network <NUM> may include an Edge application server <NUM> and one or more Edge enabler server(s) <NUM>, in communication with an Edge configuration server <NUM>. The mobile device <NUM> may include an application client(s) <NUM> in communication with one or more Edge enabler client(s) <NUM>. Each of the elements of the Edge computing system <NUM> may communicate over an Edge interface (e.g., EDGE-<NUM>, EDGE-<NUM>,. EDGE-<NUM>).

The Edge application server <NUM> and the application client(s) <NUM> each may be configured to process computing tasks, and may communicate application data traffic (i.e., data related to a computing task) via the 3GPP core network <NUM>. The Edge enabler server(s) <NUM> may be configured to maintain and advertise (e.g., to devices such as the mobile device <NUM>) applications provided by the Edge application server(s) <NUM>. The Edge configuration server <NUM> may be configured to manage communication within and among one or more Edge data networks <NUM>.

The Edge application server(s) <NUM> may provide information about its applications and their capabilities to the Edge enabler server(s) <NUM> via the EDGE-<NUM> interface. The Edge enabler server(s) <NUM> may provide information about the Edge data network <NUM> to the Edge configuration server <NUM> via the EDGE-<NUM> interface. The Edge application server(s) <NUM> and the Edge enabler server(s) <NUM> may communicate with the 3GPP core network <NUM> via the EDGE-<NUM> interface and the EDGE-<NUM> interface, respectively.

In some embodiments, the Edge enabler client(s) <NUM> may obtain information about the available Edge data networks <NUM> from the Edge enabler server <NUM> via the EDGE-<NUM> interface (and/or from the Edge configuration server <NUM> via the EDGE-<NUM> interface). In some embodiments, the Edge enabler client(s) <NUM> may obtain information about Edge application server(s) <NUM> such as available applications and their capabilities via the EDGE-<NUM> interface. In some embodiments, the Edge enabler client <NUM>, the Edge enabler server(s) <NUM>, and the Edge configuration server <NUM> may employ a discovery and provisioning procedure via their respective Edge interfaces.

The application client <NUM> may communicate with the Edge enabler client(s) <NUM> via the EDGE-<NUM> interface. In some embodiments, the Edge enabler client(s) <NUM> may obtain information about available Edge data networks <NUM> from the Edge configuration server <NUM> via the EDGE-<NUM> interface, and may coordinate the use of the Edge application server(s) <NUM> with the Edge enabler server(s) <NUM> via the EDGE-<NUM> interface. Edge enabler servers <NUM> may coordinate with one another via the EDGE-<NUM> interface.

<FIG> is a process flow diagram illustrating operations of a method <NUM> performed by a processor of an Edge computing device for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations of the method <NUM> may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>).

In block <NUM>, the processor may receive new or updated (referred to as "first") LDM data for a service area of the Edge computing device. In some embodiments, the Edge computing device may receive the first LDM data via an Edge network interface. In some embodiments, the first LDM data may be highly dynamic information (e.g., as defined in relevant ETSI standards). In some embodiments, the first LDM data may be obtained from a sensor or another information source within a threshold amount of time (e.g., two seconds, one second, <NUM>, etc.). In some embodiments, the first LDM data may include data from vehicles and mobile devices such as sensor data, image data, audio data, or operating state data of the vehicles and mobile devices. In such embodiments, the Edge computing device may determine information that should be integrated into an LDM data model.

In block <NUM>, the processor may integrate the first LDM data into an LDM data model. In some embodiments, the LDM data model represents an aggregation of LDM data for the service area of the Edge computing device.

In block <NUM>, the processor may determine second LDM data of the LDM data model that is relevant to a particular vehicle or mobile device. In some embodiments, the Edge computing device may determine the second LDM data of the LDM data model that is relevant to a particular mobile device, and may provide that determined relevant LDM data (i.e., the second LDM data) to the particular vehicle or mobile device. In some embodiments, the second LDM data may be highly dynamic LDM information (e.g., as defined in relevant ETSI standards).

In block <NUM>, the processor may provide the determined second LDM data to the particular vehicle or mobile device.

In optional operation <NUM>, the processor may repeat the operations of blocks <NUM>-<NUM> to receive first LDM data and determine second LDM data that is relevant to the particular vehicle or mobile device.

<FIG> is a process flow diagram illustrating operations that may be performed by a processor of an Edge computing device as part of the method <NUM> for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>).

In block <NUM>, the processor may generate a digital map encompassing an area within a predetermined distance of a vehicle. For example, in some embodiments a mobile device may include a computing device in a vehicle. In some embodiments, the processor may use a predetermined distance from the vehicle to generate a digital map encompassing an area within the predetermined distance. In some embodiments, the processor may dynamically determine a distance from the vehicle based on information about the vehicle. Such information may include, for example, a vehicle location, a vehicle direction and speed of motion, other vehicle kinematics information, and static LDM data about road and geographic features around the vehicle (e.g., nearby roads, topographical features, and the like). Such information may also include, for example, an observed route or path of the vehicle, path planning information from the vehicle (e.g., an intended or planned route of travel), and other suitable information.

In block <NUM>, the processor may transmit the digital map to the vehicle. In some embodiments, the digital map may be generated and transmitted in a format suitable for use in autonomous navigation of the vehicle.

The processor may perform optional operation <NUM> of the method <NUM> as described (<FIG>).

<FIG> is a process flow diagram illustrating operations that may be performed by a processor of an Edge computing device as part of the method <NUM> for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>). In blocks <NUM> and <NUM>, the processor may perform operations of like-numbered blocks of the method <NUM> as described.

In block <NUM>, the processor may receive a registration message from the particular vehicle or mobile device. In some embodiments, the registration message may include a request to receive LDM data as a service from the Edge computing device. In some embodiments, the registration message may include or be transmitted with other information from the particular vehicle or mobile device, such as planned route information, information about kinematics of the particular vehicle or mobile device, and/or other suitable information from the particular vehicle or mobile device.

In block <NUM>, the processor may determine second LDM data that is relevant to a particular vehicle or mobile device based on information included with the registration message. In some embodiments, the processor may use any information received from a particular vehicle or mobile device to determine second LDM data that is relevant to the particular vehicle or mobile device. For example, the processor may use the information transmitted from the particular vehicle or mobile device, such as planned route information, information about kinematics of the particular vehicle or mobile device, etc. to identify a route, path, or area along or through which the particular vehicle or mobile device may travel. As another example, the processor may use the information transmitted from the particular vehicle or mobile device to determine a radius, oval, or other area around the particular vehicle or mobile device. In some embodiments, the processor may use the information transmitted for the particular vehicle or mobile device, any identified route, path, or area, and/or any determined radius, oval, or other area around the particular vehicle or mobile device to determine the second LDM data that is relevant to the particular vehicle or mobile device. In some embodiments, the processor may determine highly dynamic LDM information that is relevant to the particular vehicle or mobile device.

The processor may perform the operations of block <NUM> of the method <NUM> as described (<FIG>).

In block <NUM>, the processor may receive information from a particular vehicle or mobile device regarding a planned route of the mobile device. For example, the processor may receive from the particular vehicle or mobile device path planning or route planning information related to intended motion or travel of the particular vehicle or mobile device.

In block <NUM>, the processor may determine second LDM data that is relevant to a particular vehicle or mobile device based on the planned route information. For example, the processor may use the path planning or route planning information to determine second LDM data that is relevant to the particular vehicle or mobile device. In some embodiments, the processor may determine highly dynamic LDM information that is relevant to the particular vehicle or mobile device.

In block <NUM>, the processor may perform operations including receiving vehicle or mobile device kinematics information from vehicles and mobile devices. In some embodiments, the kinematics information may include observable motions of vehicles and mobile devices, such as a direction, a speed, a path or route that has been traveled, waypoints, stops made, and other suitable observable motion information.

In block <NUM>, the processor may perform operations including determining second LDM data that is relevant to a particular vehicle or mobile device based on the particular vehicle or mobile device kinematics information. For example, the processor may use the kinematics to determine second LDM data that is relevant to the particular vehicle or mobile device. In some embodiments, the processor may determine highly dynamic LDM information that is relevant to the particular vehicle or mobile device.

<FIG> is a process flow diagram illustrating operations that may be performed by a processor of an Edge computing device as part of block <NUM> of the method <NUM> for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>).

In block <NUM>, the processor may receive data from vehicles, mobile devices and other data sources. In some embodiments, received data may include one or more of sensor data, image data, audio data, or operating state data obtained by the vehicles and mobile devices. In some embodiments, the processor may receive data from other data sources, such as roadside units (RSUs), data sources that may transmit Cooperative Awareness Message (CAM) messages or Decentralized Environmental Notification Message (DENM) messages, and a variety of Internet- or cloud-based resources.

In block <NUM>, the processor may determine from the received data whether there is any information that should be integrated into the LDM data model. For example, the processor may select from among received sensor data, image data, audio data, operating state data and/or inputs received from other data sources information that will augment or improve the LDM data model, while information that is redundant or irrelevant to the LDM data model may be ignored. In some embodiments, the processor may determine highly dynamic LDM information, as such information is defined in relevant ETSI standards, that should be integrated into the LDM data model.

<FIG> is a process flow diagram illustrating operations that may be performed by a processor of an Edge computing device as part of block <NUM> of the method <NUM> for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations of the method <NUM> may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>).

In block <NUM>, the processor may receive data from the mobile device (e.g., a computing device in a vehicle). In some embodiments, received data may include one or more of sensor data, image data, audio data, or operating state data obtained by the mobile device.

In block <NUM>, the processor may determine from the received data whether any information should be integrated into the LDM data model. For example, the processor may select mobile device sensor data, image data, audio data, and/or operating state data to determine LDM data that will augment, update or otherwise enhance the LDM data model. In some embodiments, the processor may determine highly dynamic LDM information, as such information is defined in relevant ETSI standards, that should be integrated into the LDM data model.

<FIG> is a process flow diagram illustrating operations <NUM> that may be performed by a processor of an Edge computing device as part of the method <NUM> for generating LDM data in accordance with various embodiments. With reference to <FIG>, the operations <NUM> may be performed by a processor of an Edge computing device (e.g., the Edge application server <NUM>) in an Edge network (e.g., the Edge network <NUM>, <NUM>).

Following performance of the operations of block <NUM> of the method <NUM>, the processor may generate a state representation of the mobile device in block <NUM>. For example, an EAS 184a-184c may generate a state representation of the mobile device. As noted above, the state representation may include device-descriptive information including a location, direction of motion, velocity, operational status, and other suitable information. In some embodiments, the state representation may also include a current LDM subset stored by or used by the mobile device.

In block <NUM>, the processor may determine the second LDM data relevant to the mobile device based on the generated state representation. In some embodiments, the processor may use the device-descriptive information in the state representation to determine the second LDM data relevant to the mobile device based on one or more parameters in the state representation. For example, based on a location and/or a direction of motion, the processor may include in the second LDM data certain LDM data near the location, along the direction of motion, etc..

In block <NUM>, the processor may determine delta information based on the state representation and the second LDM data. As noted above, in some embodiments, the processor may determine delta information representing differences between a state representation of the mobile device and current or recently updated LDM data.

In block <NUM>, the processor may provide the determined delta information to the mobile device. In some embodiments, the delta information may enable the mobile device to quickly and efficiently receive and implement updates to LDM data stored and used by the mobile device.

The processor may then perform the operations of block <NUM> of the method <NUM> (<FIG>) as described.

Following performance of the operations of block <NUM> of the method <NUM> (<FIG>), the processor may receive an LDM data query in block <NUM>. For example, the processor may receive a query for a location (e.g., a specific address, store, building, etc.), a type of store or building at a location (e.g., "grocery store", "coffee shop", "bank", etc.), or a type of location (e.g., "a park", "a pool," "a parking space", "a beach", etc.). As another example, the processor may receive a query for a path or directions to a location. As another example, the processor may receive a query for highly dynamic map data (e.g., "food trucks in my area", "construction zones", "accidents", "speed traps", etc.).

In block <NUM>, the processor may determine the second LDM data that is relevant to a mobile device based on the generated state representation of the mobile device and the received LDM data query. For example, based on a LDM data query "find me a parking space" and the state representation (e.g., location and vector) of the mobile device (in this example, a vehicle), the processor may scan the LDM data to identify data parking space(s) within a threshold distance (e.g., <NUM> meters) of the mobile device, or along a path of travel (e.g., on the vehicle-side of the street instead of on the opposite side of the street from the vehicle). The processor may use other information from the state representation to further determine or refine the determination of relevant LDM data. For example, the processor may use information about a size or shape of the vehicle to identify a parking space in which the vehicle may fit, and discard parking spaces that cannot accommodate the vehicle.

Following performance of the operations of block <NUM> of the method <NUM> (<FIG>), the processor may determine a trust metric for the received first LDM data based on a plurality of mobile device parameters in block <NUM>. In some embodiments, the processor may perform a security function to safeguard the integrity of the LDM data against, for example, inaccurate LDM, false LDM data, attempts to introduce inaccurate or false information into the LDM data, LDM data that is too "noisy" to be reliable, and the like. In some embodiments, the processor may determine a trust metric based on a plurality of parameters for received LDM data. In some embodiments, the processor may determine the trust metric on a per-data basis, such as each time new LDM data is received from a mobile device (such as a vehicle).

In some embodiments, the trust metric may represent a trustworthiness score or trustworthiness rating of the received LDM data. In some embodiments, the trust metric may include a figure of trust or another similar trustworthiness score. The processor may determine the trust metric based on a plurality of factors and/or determinations, each of which may increase or decrease the overall trust metric. Each such factor or determination is referred to herein as a "trust parameter.

For example, the processor may determine whether LDM data received from one mobile device can be corroborated with LDM data from another source (e.g., another mobile device, roadside unit, server, etc.). The processor may determine that LDM data that can be corroborated is more trustworthy than LDM data that cannot be corroborated, and LDM data that can be corroborated may increase the trust metric. As another example, the processor may evaluate one or more factors related to the communication link over which the LDM data is received. Such factors may include, for example, a type of connection (cellular communications are generally more trustworthy than Bluetooth or Wi-Fi communications); a number of network node hops between the source device and the processor (e.g., the EAS <NUM>); a level of communication link security (e.g., encrypted vs. non-encrypted, use of Transport Level Security (TLS), etc.); and the like. As another example, the processor may evaluate the trustworthiness of the source device, such as whether the device has been authenticated, the type and robustness of any authentication credentials presented by the source device, whether the processor can verify the credentials, whether the source device is registered with a network (e.g., a 3GPP network), whether the source device is registered with an Edge computing device (e.g., the EAS <NUM>), and the like.

In determination block <NUM>, the processor may determine whether the trust metric exceeds a trust metric threshold. The trust metric threshold may be a configurable value that be set may a network operator, an equipment manufacture, a government entity, a standards body, a law enforcement entity, etc. In some embodiments, the trust metric threshold may vary depending upon the type of vehicle, an occupant of the vehicle, a location, and other parameters.

In response to determining that the trust metric does not exceed the trust metric threshold (i.e., determination block <NUM> = "No"), the processor may not integrate the LDM data into the LDM data model in block <NUM>.

In response to determining that the trust metric exceeds the trust metric threshold (i.e., determination block <NUM> = "Yes"), the processor may perform the operations of block <NUM> of the method (<FIG>) as described to integrate the LDM data into the LDM data model.

Following the operations of block <NUM>, the processor may perform the operations of block <NUM> of the method <NUM> (<FIG>) as described.

Various embodiments may be implemented on a variety of network devices, an example of which is illustrated in <FIG> in the form of an Edge computing device <NUM> functioning as a network element of a communication network, such as an Edge application server, an Edge enabler server, or an Edge data network configuration server. Such network computing devices may include at least the components illustrated in <FIG>. With reference to <FIG>, the Edge computing device <NUM> may typically include a processor <NUM> coupled to volatile memory <NUM> and a large capacity nonvolatile memory, such as a disk drive <NUM>. The Edge computing device <NUM> may also include a peripheral memory access device such as a floppy disc drive, compact disc (CD) or digital video disc (DVD) drive <NUM> coupled to the processor <NUM>. The Edge computing device <NUM> may also include network access ports <NUM> (or interfaces) coupled to the processor <NUM> for establishing data connections with a network, such as the Internet and/or a local area network coupled to other system computers and servers. The Edge computing device <NUM> may include one or more antennas <NUM> for sending and receiving electromagnetic radiation that may be connected to a wireless communication link. The Edge computing device <NUM> may include additional access ports, such as USB, Firewire, Thunderbolt, and the like for coupling to peripherals, external memory, or other devices.

In addition to the vehicle systems described with reference to <FIG>, various embodiments may be implemented on a variety of mobile devices (e.g., the mobile devices 120a-120e), an example of which is illustrated in <FIG> in the form of a smartphone <NUM>. The smartphone <NUM> may include a first SOC <NUM> (e.g., a SOC-CPU) coupled to a second SOC <NUM> (e.g., a <NUM> capable SOC). The first and second SOCs <NUM>, <NUM> may be coupled to internal memory <NUM>, <NUM>, a display <NUM>, and to a speaker <NUM>. Additionally, the smartphone <NUM> may include an antenna <NUM> for sending and receiving electromagnetic radiation that may be connected to a wireless data link and/or cellular telephone transceiver <NUM> coupled to one or more processors in the first and/or second SOCs <NUM>, <NUM>. Smartphones <NUM> typically also include menu selection buttons or rocker switches <NUM> for receiving user inputs.

A typical smartphone <NUM> also includes a sound encoding/decoding (CODEC) circuit <NUM>, which digitizes sound received from a microphone into data packets suitable for wireless transmission and decodes received sound data packets to generate analog signals that are provided to the speaker to generate sound. Also, one or more of the processors in the first and second SOCs <NUM>, <NUM>, wireless transceiver <NUM>, and CODEC <NUM> may include a digital signal processor (DSP) circuit (not shown separately).

The processors of the Edge computing device <NUM> and the smart phone <NUM> may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described below. In some mobile devices, multiple processors may be provided, such as one processor within an SOC <NUM> dedicated to wireless communication functions and one processor within an SOC <NUM> dedicated to running other applications. Typically, software applications may be stored in the memory <NUM>, <NUM> before they are accessed and loaded into the processor. The processors may include internal memory sufficient to store the application software instructions.

A number of different cellular and mobile communication services and standards are available or contemplated in the future, all of which may implement and benefit from the various embodiments. Such services and standards include, e.g., third generation partnership project (3GPP), long term evolution (LTE) systems, third generation wireless mobile communication technology (<NUM>), fourth generation wireless mobile communication technology (<NUM>), fifth generation wireless mobile communication technology (<NUM>), global system for mobile communications (GSM), universal mobile telecommunications system (UMTS), 3GSM, general packet radio service (GPRS), code division multiple access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), enhanced data rates for GSM evolution (EDGE), advanced mobile phone system (AMPS), digital AMPS (IS-<NUM>/TDMA), evolution-data optimized (EV-DO), digital enhanced cordless telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), wireless local area network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), and integrated digital enhanced network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and/or content messages. It should be understood that any references to terminology and/or technical details related to an individual telecommunication standard or technology are for illustrative purposes only, and are not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments that are shown and described. Further, the claims are not intended to be limited by any one example embodiment. For example, one or more of the operations of the methods <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be substituted for or combined with one or more operations of the methods <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of receiver smart objects, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage smart objects, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable storage medium and/or computer-readable storage medium, which may be incorporated into a computer program product.

Claim 1:
A method (<NUM>,<NUM>) performed by an Edge computing device for generating local dynamic map, LDM, data, the method (<NUM>) comprising:
receiving a registration message from a mobile device, the registration message including a request to receive LDM data as a service from the Edge computing device;
receiving (<NUM>) first LDM data for a service area of the Edge computing device;
integrating (<NUM>) the first LDM data into an LDM data model, representing an aggregation of LDM data for the service area of the Edge computing device;
determining (<NUM>) second LDM data of the LDM data model that is relevant to the mobile device based on information included with the registration message; and
providing (<NUM>) the determined second LDM data to the mobile device.