CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This present application is a non-provisional filing of, and claims benefit under 35 U.S.C § 119(e) from, U.S. Provisional Patent Application Serial No. 62/377,202, entitled "Method for Changing the Lead Vehicle of a Vehicle Platoon," filed August 19, 2016, the entirety of which is incorporated herein by reference.

BACKGROUND

[0002] Platooning will be one of the first targets concerning automation of commercial heavy vehicles. However, platooning is subject to various practical and technical requirements. For example, passenger cars are generally not allowed to follow a platoon of heavy vehicles, and it may be required that the front vehicle of a platoon have a driver. There will be both manually- driven cars and autonomous cars in the same traffic environment for several decades. One issue that is likely to arise is how autonomous platoons with 3-7 vehicles will account for platoon configuration changes when drivers cannot pass a whole platoon at one time. On a multi-lane highway, there are separate lanes that can be used for passing a platoon. However, platoons are intended to be used not only on multi-lane highways, but also on, for example, a two-lane country road with hills and on-coming traffic.

[0003] Ensuring latency times for splitting and merging platoons may be a challenge when the lead vehicle is changed. It is desirable to determine, within a few seconds of a platoon becoming fragmented, which vehicle will be assigned the lead driver (or supervisor) role. Current platooning applications are based mostly on information received from vehicle-to- vehicle (V2V) communication channels and longitudinal distance detection systems (e.g., radar). However, these systems focus on vehicle kinetic data by optimizing smooth travelling, and these systems do not account for reconfiguring a platoon's structure while driving. Currently, structure changes are communicated to other drivers without determining if another driver is able to be assigned the lead driver (or supervisor) role according to European Telecommunications Standards Institute (ETSI) report Intelligent Transport System (ITS): Cooperative Adaptive Cruise Control (CACC): Pre- Standardization Study, ETSI TECHNICAL REPORT 103 299, (2016) (Release 2). Today, platoons are considered to be disbanded if another driver is unable to take on the lead driver (or supervisor) role. This makes the platooning function inefficient, annoying and even unsafe. SUMMARY

[0004] Methods and systems disclosed herein are used to support autonomous vehicle platoons for a platoon structure reconfiguration. In many real world traffic scenarios, vehicle platoons split, merge, or move to two-lane roads. In these cases, the platoon leader or supervisor may change to a different driver. Such situations may occur due to an incident or obstacle in the road, a sensor system failure, or an exiting of vehicles to follow another route.

[0005] An exemplary system uses existing drivers and operators to support situation awareness systems to continue an autonomous driving mode without disbanding a platoon. The system may be triggered by abnormal traffic situations reported by other vehicles to an intelligent transport system (ITS) service station or to the leader of the platoon. The lead vehicle (in which the responsible driver rides) determines whether to use support from a human and selects an available driver to take over the lead driver (or supervisor) role.

[0006] A platoon may already include a driver who, via an application (such as a "see through" application as described below), may take over control of the platoon and support splitting the platoon into mini-platoons. One embodiment continuously updates a table accessible to the lead vehicle (the vehicle which supervises a platoon) concerning driver availability to take over platoon supervision. One embodiment continuously monitors whether to split or merge a platoon and whether a driver may be able to take over platoon supervision.

[0007] Methods and systems disclosed herein receive, from each vehicle associated with a platoon in a first platoon configuration, information regarding driver availability of a driver associated respectively with each vehicle. Responsive to a determination that the first platoon configuration is not appropriate for an upcoming route segment, methods and systems disclosed herein: (1) determine platoon configuration options that are appropriate for the upcoming route segment; (2) select a second platoon configuration such that the driver availability received by a vehicle is compatible with serving a lead driver role in the second platoon configuration; and (3) transmit platoon configuration information about the second platoon configuration to each vehicle associated with the platoon to instruct the vehicles to operate in accordance with the second platoon configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be had from the following description, presented by way of example in conjunction with the accompanying drawings.

[0009] FIG. 1 is a concept view schematic of a collaborative vehicle platooning scenario. [0010] FIG. 2 is an exemplary user interface diagram of a user interface displaying a lead driver role message.

[0011] FIG. 3 is a plan view schematic of a platoon split for a scenario where an obstacle partially blocks a lane.

[0012] FIG. 4 is a system block diagram of communication between two or more autonomous vehicles, an ITS service station, and another car.

[0013] FIG. 5 is a message sequence diagram for a method of updating a driver availability look-up table.

[0014] FIG. 6 is a message sequence diagram for a method of splitting a platoon and setting up a new leader.

[0015] FIG. 7 is a message sequence diagram for a method of setting up a new leader of a platoon.

[0016] FIG. 8 is a flowchart for a method of updating a driver availability look-up table.

[0017] FIG. 9 is a flowchart for a method of splitting a platoon and determining a new leader.

[0018] FIG. 10 is an exemplary user interface diagram for displaying messages for changing lane alignment and changing vehicle speed.

[0019] FIG. 11 is a plan view schematic illustrating a method of setting up a new leader of a platoon.

[0020] FIG. 12A depicts an example communications system in which one or more disclosed embodiments may be implemented.

[0021] FIG. 12B depicts an example wireless transmit/receive unit (WTRU) that may be used within the communications system of FIG. 12A.

[0022] FIG. 12C depicts an example radio access network (RAN) and an example core network that may be used within the communications system of FIG. 12 A.

[0023] FIG. 12D depicts a second example RAN and a second example core network that may be used within the communications system of FIG. 12 A.

[0024] FIG. 12E depicts a third example RAN and a third example core network that may be used within the communications system of FIG. 12 A.

[0025] FIG. 12F depicts an exemplary network entity that may be used within the communication system of FIG. 12 A. [0026] The entities, connections, arrangements, and the like that are depicted in— and described in connection with— the various figures are presented by way of example and not by way of limitation.

DETAILED DESCRIPTION

[0027] Existing systems re-configure platoons to allow new vehicles to j oin to the platoon and leave the platoon. In some cases, it may be desirable to change the leadership of the platoon. However, two drawbacks exist when a platoon includes both fully autonomous vehicles (without drivers or passengers on-board) and manually-driven vehicles. First, these systems do not account for driver availability and ability for a vehicle driver to be assigned a lead driver (or supervisor) role. Autonomous platooning may result in a monotonic driving environment where a driver may become drowsy or not pay attention to the driving task; such a driver may be ill-suited for taking on a role as lead driver. Second, these systems are unable with low latency times (less than 5 seconds) to split a platoon into two or more mini-platoons and assign leadership to a new driver without disbanding the whole platoon.

[0028] For safety reasons, autonomous vehicles in these cases stop autonomous driving mode and request drivers to resume control. Alertness of drivers varies depending on drowsiness level and engagement with non-driving tasks (e.g., reading a newspaper or surfing the Internet). During semi-autonomous driving, people tend to start thinking about something other than driving. Reverting driving back to a person takes away from the person's ability to do other tasks and may be dangerous if the person is drowsy.

[0029] This disclosure describes systems and methods that update driver state and determine whether and how a platoon may be split into two or more mini-platoons or merged with another platoon. For some embodiments, a system may receive via a V2X channel from other vehicles or from an ITS service station a message requesting a platoon configuration change. This message may be sent for safety reasons or for maintaining autonomous platooning mode. A platoon may be split into two platoons for multiple reasons, such as overtaking the lead vehicle (or front vehicle) in two sections or passing through road maintenance work where passenger cars use one lane and trucks use another lane.

[0030] Exemplary methods allow vehicle platoons to survey real world road conditions (also called incidents in this specification) and determine when a platoon split or merge is beneficial. Mini-platoons may pass the incident more easily than a larger platoon, while manual driving may be avoided. Such methods may reconfigure a platoon (even if all vehicles do not have a driver) by assigning a lead driver (or supervisor) role to a vehicle in which a driver is available behind the steering wheel. Such a lead driver role may be assigned in some embodiments even to a driver whose vehicle is not the front vehicle.

[0031] For some embodiments, a system operates to reconfigure (split and merge a platoon into multiple parts) based on detected incidents. For some embodiments, trigger data that activates platoon reconfiguration may be received from a V2X communication channel or a vehicle environment perception system. Also, a system may generate different types of platoons, such as splitting into two or more smaller platoons or switching to two-lane platooning to take a detour to avoid an accident (or other incident). An exemplary system operates to recognize and categorize drivers in a platoon according to a driver's availability to take over the lead driver (or supervisor) role.

[0032] FIG. 1 is a plan view schematic of a scenario 170 where a platoon is split when a non- platoon vehicle passes only part of the platoon. The scenario may occur on a two-lane road where a non-platoon vehicle 175 starts to pass the platoon. Before the non-platoon vehicle 175 finishes passing the platoon, an on-coming car 171 appears in the opposite lane. The non-platoon vehicle 175 returns to the right hand lane and splits the platoon in the process. For the example shown in FIG. 1, three of the platoon vehicles 172, 174, 176 have drivers (shown with a checkmark), while two vehicles 173, 177 have no driver available (shown with an "x"). A driver is available in some vehicles to take over a lead driver role in a platoon if the platoon is split into multiple mini- platoons.

[0033] For one embodiment, the lead vehicle 172 (the one which supervises the platoon) stores a driver availability look-up table (or "look-up table"), which may be a plurality of memory locations, concerning availability (and capability) of drivers to take over platoon supervision if the platoon is reconfigured. Driver availability may be based on whether a driver is distracted, drowsy (or lacking a safe level of alertness), or not behind the steering wheel. For some embodiments, the look-up table is continuously-updated. If a split function is activated, a system checks the look-up table to determine which vehicles may be assigned the lead driver role in the platoon. In some embodiments, a "see-through" application or other user interface is present in all vehicles. For one embodiment, a lead vehicle 172 with an in-vehicle environment 178 may communicate via V2X communication 193 to a vehicle 174 with a driver present and an in-vehicle environment 179. The vehicle 174 may communicate via V2X communication 195 to a vehicle 176 selected to be a lead vehicle of a sub-platoon of the platoon. An in-vehicle view 191 of the first lead vehicle 172 may be communicated to the second lead vehicle 176.

[0034] Exemplary technology that may be used to implement a see-through application is described in, for example, Gomes, F. Vieira, and M. Ferreira, The See-Through System: From Implementation to Test-Drive, IEEE VEHICULAR NETWORKING CONFERENCE (VNC), 14- 16 NOV. 2012, SEOUL, SOUTH KOREA, (2012). The see-through application or other application may also operate to display reasons for a platoon split. The user interface may be used to show a message received via a V2X channel regarding an incident (such as road construction or an on-coming vehicle) and to enable a driver to have enough time to make an adjustment.

[0035] FIG. 2 is an exemplary user interface 200 for displaying a message 201 asking if the driver is able to accept a lead driver role, such as an interface of a see-through application. The system may display information on the reason for splitting. For some embodiments, underneath a text box displaying the message, two buttons 202, 203 are displayed. The user may press "Yes" or "No" to accept or reject, respectively, the lead driver role when the platoon is split. For other embodiments, an external keyboard is used by the driver to accept or reject the lead driver role. The see-through application may send an acknowledgement message to the other platoon vehicles that indicates whether the driver accepts or rejects the offer to be a platoon leader.

[0036] FIG. 2 also shows an example user interface display for a narrowing of a lane. The user interface displays a warning message 204 on a video screen with a view of the road segment ahead. For the example shown in FIG. 2, the warning message shows the text line "Lane width <3 m" underneath a warning triangle symbol.

[0037] For some embodiments, when an in-vehicle computer detects an incident or lane obstacle that may result in a platoon split, the computer will calculate an optimal number of mini- platoons. Other vehicles may be allowed to be assigned the lead driver (or supervisor) role after checking which vehicles are available. Also, a system will minimize manual driving and generate an optimal number of mini-platoons.

[0038] FIG. 3 shows an example 300 where an obstacle 322 partially blocks a lane and leaves only passenger cars 3 16, 320 with enough room to pass the obstacle. Big trucks 302, 304, 308 will move to a different lane to avoid the obstacle 322 as shown on the right of FIG. 3 as trucks 3 12, 314, 3 18. In this scenario, passenger cars 306, 3 10 form a new mini-platoon of cars 3 16, 320 on the right side of FIG. 3. The new mini-platoon of cars 3 16, 320 may make changes, such as slowing down and making maneuvers to pass the obstacle 322, that are not performed by the platoon of big trucks 3 12, 3 14, 3 18. The platoon leader 302 may continue as platoon leader 1 (3 12) of the big trucks 3 12, 3 14, 3 18 while platoon leader 2 (3 16) leads the mini-platoon of cars 3 16, 320.

[0039] FIG. 3 shows a scenario 300 where an obstacle 322 partly blocks a lane being used by a vehicle platoon. A system interacts with two or more vehicles that are part of the platoon. In some scenarios, a vehicle in the platoon may detect an obstacle in the road. The existence of this obstacle may be communicated to other vehicles and to an ITS service station. The lead vehicle 302 receives information from other vehicles 304, 306, 308, 310 in the platoon or from an ITS service station via V2X communication of an incident detected message. The warning may be received when the lead vehicle 302, 312 is about 300 - 800 m away 324 from the obstacle 322. This distance 324 enables the platoon to have time to react to the incident. For some scenarios, the platoon will be split into two or more mini -platoons. An exemplary size platoon may be 3 to 10 vehicles, while a mini-platoon may be even 2 vehicles.

[0040] For some embodiments, a system may react to a situation where a platoon may use driver interaction. One option has a system sending platoon leader request messages to platoon vehicles with a compatible driver. These messages are sent to determine if another vehicle driver will take over control and supervision of the platoon when the state of the lead vehicle driver is drowsy or distracted, for example. Another option splits the platoon into two or more mini- platoons and determines lead vehicle drivers (or supervisors) for each mini-platoon from the group of drivers who are available, behind the wheel, properly licensed, and not too distracted to take over the driving task. Two platoons or mini-platoons may merge together for efficiency, safety, or other criteria.

[0041] For some embodiments, driver state analysis is executed continuously as a separate process that uses a look-up table stored on the lead (or first) vehicle of the platoon. Moreover, driver background information is added to the look-up table to communicate to the driver of the lead vehicle the level of driving experience of each driver in the platoon. When an incident message is transmitted, a system checks the look-up table to determine what vehicle and driver support is available. A support message is sent to only vehicles with drivers who may be available to take over the lead vehicle position for the platoon.

[0042] Minimizing latency time reduces risk when control of the platoon is handed over to a new driver. Via the vehicle human-machine interface (HMI), the driver acknowledges that he or she will take over the control of the platoon. The selected driver receives perception data from the lead vehicle of the platoon, and this data is displayed via the see-through application or another available user interface environment. Incident information is also provided for the vehicle driver. An exemplary system operates to maximize use of autonomous mode for platooning vehicles while minimizing interventions with drivers and vehicle occupants.

[0043] FIG. 4 is a block diagram 400 showing interface components and system communication connections. Each platooning vehicle 402, 404 (vehicles 1, 2, and any additional vehicle in the platoon) may have the following modules and components: a communications unit

412, 420, a human-machine interface (HMI) 414, 422, a driver state analysis module 416, 424, and a platooning function 418, 426. A communications unit 412, 420 may use a data exchange channel (such as DSRC and 5G) 410 to transmit and receive data to and from platooning vehicles 402, 404, other vehicles 406, and ITS service stations 408. An HMI module 414, 422 may show the status of the environment perception data, incident messages, and video from the lead vehicle or other vehicles in the platoon. The HMI 414, 422 also receives an acknowledgment message from another platoon vehicle that the driver of that vehicle accepts or rejects a lead driver role. A driver state analysis module 416, 424 monitors a driver's availability (based on workload, drowsiness, and being in the driver's seat) and provides support to a vehicle computer system. The module 416, 424 may also store in memory driver characteristics, such as professional truck driver status, young driver status, and experience as a driver, and communicate those characteristics to other modules and systems. Each driver state analysis module 416, 424 transmits updates to the lead vehicle to store in a look-up table. The driver availability look-up table may be continuously or regularly updated with driver availability (which includes driver alertness level/state) for each vehicle in the platoon. A platooning function is a module that controls platoon control parameters, such as distance, speed, direction, lane alignment, and IDs of vehicles in the platoon) and functionality level (manual or autonomous driving mode).

[0044] For other vehicles 406 (which may or may not be part of the platoon) that detect a road incident, two modules may be used: a communications unit 428 and a perception system 430. For some embodiments, a lead vehicle in a platoon may also communicate with other vehicles outside the platoon as the platoon approaches such other vehicles. These other vehicles 406 are labeled as "Car 2: Other Car or Vehicle." This vehicle 406 also may be a truck or other vehicle for some embodiments. A communications unit 428 is used to receive and transmit data with platooning vehicles. A perception system 430 detects road hazards, incidents (such as accidents), and obstructions and objects around a vehicle or in a lane of traffic.

[0045] Other vehicles 406 provide driver state analysis information continuously to the lead vehicle which hosts decision making and control functions for the whole platoon. The lead vehicle may have the best visual view for events in front of the platoon. Video from the lead vehicle may be displayed on a see-through video display module within each vehicle in the platoon. For some embodiments, when a new leader (or supervisor) is determined to lead a platoon, the see-through video display may switch to another vehicle.

[0046] An ITS service station 408 may use two modules as part of a unit's interactions with other system components: a communications unit 432 and a traffic and road data module 434. A communications unit 432 receives and transmits data from and to platooning vehicles. A traffic and road data module 434 is a database for storing in memory traffic and road incidents. This database 434 may be used by the communications unit to transmit and receive data for use by platooning vehicles.

[0047] FIG. 5 is a message sequence diagram 500 for updating a driver availability look-up table. The look-up table may be stored in the lead vehicle 502 for a platoon. A lead vehicle 502 sends a RequestDriverState message 506 to every other vehicle 504 in the platoon. For some embodiments, this message 506 is sent on a periodic basis to each other vehicle 504 in the platoon. This request message 506 pings other vehicles 504 for updates to a driver's state of availability. Other vehicles 504 receive these request messages 506 and analyze a driver's state of availability 508.

[0048] Other vehicles 504 respond to RequestDriverState messages 506 with DriverState messages 510. The state of the driver is stored by the on-board driver monitoring unit. The driver monitoring unit may include cameras for assessing driver facial features, speed, and acceleration data for profiling the driver. The driver monitoring analysis may also be based on vehicle-based parameters, such as speed variation, micro-steering, accelerations, and decelerations. For some embodiments, a driver state analysis is done by displaying a message on an FDVII and recording the driver' s response to a driver availability message. A DriverState response message may contain fields for vehicle ID and driver status. The vehicle ID is an identification code for a vehicle in a platoon, and the driver status is a value corresponding to the state of the driver (drowsy, distracted, or no driver available).

[0049] An UpdateLookUpTable command 512 is a command sent by a lead vehicle 502 to a module updating the driver availability look-up table. The table may be stored in the lead vehicle 502. This table is used to determine a driver for leading a platoon if an existing lead driver (or supervisor) requests a change. This message 512 contains three fields: NumberPlatooningVehicles, DriverStateLookUpTable, and DriverState. The NumberPlatooningVehicles is the number of vehicles in the platoon. This field is also the size of the DriverStateLookUpTable. The DriverStateLookUpTable is a series of values holding the state of each driver in the platoon. For some embodiments, the DriverStateLookUpTable field may be a pointer to a memory location where the table is stored. For each entry in the DriverStateLookUpTable, the state of each platooning vehicle's driver is stored. This DriverState variable may be drowsy, distracted, or no driver available.

[0050] Various technologies may be used by a vehicle for determining driver availability and alertness levels. Exemplary technologies that may be employed are those described in US Patent

No. 8,874,301, entitled "Autonomous vehicle with driver presence and physiological monitoring."

Driver alertness (or driver distraction level/state) may be determining using techniques such as detecting human facial features, in-vehicle steering activity, and longitudinal speed variation parameters using methods described in, for example, M. Kutila, M. Jokela, G. Markkula, and M. R. Rue, Driver Distraction Detection with a Camera Vision System, Vol. VI PROCEEDINGS OF THE IEEE INTERNATIONAL CONFERENCE ON IMAGE PROCESSING (ICIP) 201-204 (Sep. 16-19, 2007). Another embodiment may use a decomposed component of a steering wheel control signal to determine whether a driver is alert or drowsy using, for example, techniques described in U.S. Patent 8,519,853, entitled "Unobtrusive Driver Drowsiness Detection System and Method."

[0051] FIG. 6 is a message sequence diagram 600 for a scenario where a platoon is split into two or more mini-platoons. A lead vehicle 604 sends a RequestlncidentMap message 608 to a trigger system 602. A trigger system (or trigger) 602 for reconfiguring a platoon or selecting a new lead (or supervisor) vehicle may determine whether a particular driving scenario may benefit from a reconfiguration of a platoon.

[0052] The trigger system 602 responds to the RequestlncidentMap message 608 with an IncidentMap message 610. This message 610 communicates incidents (both dynamic and static) in front of the lead vehicle 604 of a platoon in response to a request by the lead vehicle 604. The message content may use the format described in ETSI Technical Report 102 863, Intelligent Transport Systems (ITS): Vehicular Communications: Basic Set of Applications: Local Dynamic Map (LDM): Rationale for and Guidance on Standardization, ETSI TECHNICAL REPORT 102 863 (2011) (Section 7.5.3 : Location and Dimensions of Hazard, Version 1.1.1, 2011-08). For one embodiment, the message contains three fields: Location, Hazard Type, and Traffic Status. The Location field contains the location of hazard event (or incident). The Hazard Type field is the type of hazard (congestion, accident, road work, narrowing of the road, and 31 other conditions listed in the ETSI Technical Report 102 863). The Traffic Status field contains the status of traffic (such as queuing traffic, slow traffic, and 6 other conditions listed in the ETSI Technical Report 102 863). Other embodiments also contain Lane Identifier and Report Propagation fields mentioned in ETSI Technical Report 102 863. The Lane Identifier field is the highway lane affected by the hazard. The Report Propagation field contains the direction and range of propagation of the hazard.

[0053] If the current lead vehicle driver will soon be unavailable, a driver availability check 612 may be performed by reading a look-up table stored in memory and determining a compatible driver to be a new lead vehicle of the platoon. A RequestPlatoonLeader message 614 is transmitted from the lead vehicle to another vehicle in the platoon. This message 614 requests a driver associated with a selected driver to take over control of a platoon. The driver replies via the HMI display, and an Acknowledgement message 616 is sent back to the lead vehicle 604. An Acknowledgement message 616 is a status message that indicates whether the driver accepts or rejects the request to take over the lead driver role for the platoon. This message field may take a value of either yes (accept) or no (reject).

[0054] With a new lead vehicle assigned, a PlatoonSplitCommand message 618 is sent to each vehicle in the platoon. The PlatoonSplitCommand message 618 contains at least 4 different fields: NumberOfPlatoons, PlatoonLeaderlD, Platoon Vector 1, and PlatoonVector2. The NumberOfPlatoons field is the number of platoons after the split. The PlatoonLeaderlD field is the vehicle ID of the vehicles that are new lead vehicles. PlatoonVectorl field contains the vehicle IDs for the vehicles that will be in mini -platoon number 1. PlatoonVector2 field contains the vehicle IDs for the vehicles that will be in mini-platoon number 2. More Platoon Vector fields will be included in the message if there will be 3 or more mini-platoons after the split. With a new leader selected, each vehicle in the platoon is commanded to complete the reconfiguration. This reconfiguration may be a splitting of a platoon, a combining of the platoon with another platoon, or a reassignment of the lead driver role. For some embodiments, a desirable platoon configuration may be determined by using techniques describe in U.S. Patent 8,352, 112, entitled "Autonomous Vehicle Management."

[0055] For one embodiment, the process of determining lead vehicle drivers determines a ranked order of compatible drivers for a lead driver role. This order may be determined, for example, based on a vehicle's location within the platoon, the sensor abilities of a vehicle, and the driver's driving ability. A compatible driver is one that is available, behind the wheel, properly licensed, and not distracted to take over the driving task. The lead vehicle 604 transmits a RequestPlatoonLeader (or lead driver role request) message 614 to the vehicle with the highest ranked compatible driver. The vehicle 606 with the compatible driver responds with an Acknowledgement (or lead driver role response) message 616. If the vehicle 606 responded with a rejected field value in the Acknowledgement message 616, the process repeats and transmits a RequestPlatoonLeader (lead driver role request) 614 message to the next highest ranked compatible driver. If the vehicle responded with an accept field value in the Acknowledgement message 616, the lead vehicle 604 transmits a PlatoonSplitCommand message 618 to each vehicle 606 in the platoon. If the lead vehicle 604 transmits a RequestPlatoonLeader (lead driver request) 614 to every compatible driver on a list of compatible drivers in the platoon and receives a rejected field value in each respective Acknowledgement message 616, the lead vehicle 604 may disband the platoon by sending a message to each vehicle in the platoon to switch to manual driving mode. For one embodiment, the process of determining lead vehicle drivers for a new platoon configuration is performed by a lead vehicle 604 of the current platoon configuration. For one embodiment, the process of determining lead vehicle drivers for a new platoon configuration is performed by an external sever.

[0056] Incident data is transmitted to the lead vehicle and displayed to inform the driver of a situation that may cause a platoon to be split into two or more mini-platoons. A PerceptionData message 620 is sent from the lead vehicle to a platoon vehicle. This message contains perception data for visualizing an object undetected (or unknown) by platoon vehicles other than the lead vehicle. The message has 2 fields: UnknownObject and ObjectPositon. The UnknownObject field contains information concerning the undetected (or unknown) object (such as size or color). The ObjectPosition field is the position of the object in the World Geodetic System 1984 (WGS84) coordinate system. The coordinates are in the global frame of the platoon.

[0057] When a new driver is selected and the driver accepts the lead driver role, see-through video of the current front vehicle is transmitted to the HMI display in the new leader vehicle. A SendVideoData message 622 is sent from the lead vehicle 604 to another vehicle 606 in the platoon. The message 622 contains video data captured by the lead vehicle 604 in assessing an undetected (or unknown) object. The message 622 has one field, VideoDataStream. The VideoDataStream field is a video data stream that is recorded by a camera attached to the lead vehicle.

[0058] Once a vehicle has completed that vehicle's portion of a platoon split, a response is sent back to the previous lead vehicle. A PlatoonSplitStatus message 624 is sent from the platoon vehicle back to the former lead vehicle. The message communicates that the vehicle's portion of the platoon split is completed and a new lead (or supervisor) vehicle has been assigned.

[0059] FIG. 7 is a message sequence diagram 700 of a system when the lead driver role is changed to a new vehicle and driver. FIG. 7 is similar to FIG. 6 except that FIG. 7 applies to a change in the lead vehicle 704 for the platoon but no other reconfiguration of the platoon, while FIG. 6 applies to a split in a platoon vehicle layout. As a result, FIG. 7's scenario has all the same messages as FIG. 6 except for the transmitting of PlatoonSplitCommand and PlatoonSplitStatus messages.

[0060] For one embodiment, a Lead Vehicle 704 sends a RequestlncidentMap message 708 to a Trigger System 702, which responds with an IncidentMap message 710. The Lead Vehicle 704 checks for driver availability 712 and sends a RequestDriverSupport message 714 to a Platoon Vehicle 706. A Platoon Vehicle 706 responds with an Acknowledgement 716.

[0061] For setting up a new leader of the platoon if the driver approved, the Lead Vehicle 704 sends a PerceptionData message 718 and a SendVideoData message 720 to a Platoon Vehicle 706 corresponding to the new platoon leader. The Platoon Vehicle 706 executes driving commands 722 to move into position as the new platoon leader.

[0062] FIG. 8 is a flowchart 800 of the steady state driver state analysis system that monitors driver availability and updates a driver availability look-up table. If a plurality of vehicles forms a platoon and switches to platoon mode 802, several initial conditions exist. Each vehicle in the platoon is in platooning mode. Vehicle 1 is the front (or lead) vehicle and master (or controller) of the platoon. At least vehicle 1 and one other vehicle have a driver behind the steering wheel. A person behind a steering wheel may not actually be driving a vehicle. A "see-through" application is running continuously in the front vehicle to transmit video data to the other vehicles in the platoon and to enable other drivers a front view of the platoon.

[0063] When all of the vehicles in a platoon are in platoon mode, a system (or lead vehicle for some embodiments) sends driver availability requests to each vehicle in the platoon. Driver availability may be determined based on whether a driver is distracted, drowsy, or not behind the steering wheel 804. Each non-lead (or other) vehicle measures or determines a driver's state 808 and responds with a driver state update 806. The lead vehicle receives the update messages and stores 806 the updated information in the driver availability look-up table. The updating process repeats continuously for each vehicle until a vehicle's driver or system discontinues autonomous platooning mode. The remaining platooning vehicles continue the updating process.

[0064] FIG. 9 is a flowchart 900 for a method of splitting a platoon and determining a new platoon leader (or supervisor). FIG. 9 may be performed in addition to the process shown in FIG. 8. The lead vehicle of a platoon receives an incident warning message 902. For some embodiments, this message may be received via a V2X communications channel. Other vehicles or an ITS service station may detect an incident in the upcoming route segment. For some embodiments, the lead vehicle's perception system may detect an incident. Receiving an incident warning message or detecting an incident by a lead vehicle may trigger interaction messages with platoon vehicle drivers to split the platoon or to change the leader (or supervisor) of the platoon. The lead vehicle's in-vehicle computer system checks 904 a look-up table to determine availability of drivers (or operators) in the platoon. A new platoon configuration is determined 906, which may split the platoon into two or more mini-platoons. A request is sent 908 to a perspective new platoon leader. The driver interacts 910 with an UMI display to respond to the request 908 about taking over control of the platoon. If the driver responds "No," the process repeats the look-up table check 904 to determine driver availability. If the driver responds "Yes," sensor data (such as location of the detected object) and video data from the front vehicle are transmitted to a new lead vehicle (based on a new platoon configuration (or mini-platoons) 914) to enable a new driver to see 916 the incident message and to assess why platoon control is being switched or reconfigured. The platoon is also split 918 and a new lead vehicle and driver are assigned 920 control over a new mini- platoon. If the platoon is split 918 into three or more mini -platoons, the process shown in FIG. 9 may be repeated multiple times to assign a lead vehicle and driver to each mini-platoon.

[0065] Combining the methods of FIGs. 8 and 9, a lead vehicle receives from each vehicle in a platoon messages containing information about driver availability. FIG. 8 shows this process as a series of requests and responses regarding driver availability. The information in these messages is saved to a driver availability look-up table. FIG. 9 illustrates a circumstance in which an incident warning message is received, and a system determines that the present platoon configuration is not appropriate for the incident present in the upcoming route segment. For some embodiments, a system may determine that the present platoon configuration is not appropriate for the upcoming route segment because there is, for example, a vehicle accident, a lane obstruction, a splitting of vehicle traffic into trucks and cars, or a change in the upcoming route segment to use only one lane for a direction of travel of the platoon. The determination that the present platoon configuration is not appropriate for the upcoming route segment based on conditions (such as road and weather) of the upcoming route segment, the length of time the road or weather condition is calculated to last, and a lack of an available lead driver for the upcoming route segment. The lead vehicle uses the driver availability look-up table as part of a process to determine a new platoon configuration. A system may operate to determine a plurality of platoon configuration options that are appropriate for the upcoming route segment. Appropriateness is determined based on at least the received incident warning message. For one embodiment, a system selects a new platoon configuration based on a ranking of the appropriate platoon configuration options. The ranking, for one embodiment, is based at least on conditions (such as road and weather) of the upcoming route segment, the length of time the conditions are predicted to last, and availability of a driver for a lead driver role. A system sends a request message to a perspective new platoon leader. The vehicle associated with the perspective new platoon leader sends a response message back to the lead vehicle after the perspective new platoon leader either accepts or rejects the lead driver role request. The process of FIG. 9 (900) repeats with the next highest ranked perspective new platoon leader until a perspective new platoon leader accepts or a lead driver role request has been sent to all of the available drivers in the platoon. If a system selects a new platoon configuration, the lead vehicle transmits platoon configuration information to each vehicle in the platoon. The platoon configuration information is transmitted to the vehicles in the platoon via messages with a mini- platoon or convoy identifier, a lead vehicle identifier, and a position number in the mini-platoon (or convoy) for the follower vehicle. For one embodiment, the platoon configuration information may be transmitted to an ITS service station. The platoon vehicles perform actions, such as changing lanes to follow a new lead vehicle for a mini-platoon, in accordance with the selected platoon configuration.

[0066] For one embodiment, the combined process for FIGs. 8 and 9 is performed by the lead vehicle of the present platoon configuration. The present platoon configuration is the configuration of the platoon before a split or merge of the platoon was performed. For another embodiment, the combined process for FIGs. 8 and 9 is performed by an external server.

[0067] A variation of the embodiment shown in FIG. 9 is an embodiment in which the lead vehicle of a platoon is changed but the platoon is not split into two or more mini-platoons. This embodiment has a flowchart similar to FIG. 9 except that the "Split the platoon" and the "Take over the mini-platoon control" steps are not performed.

[0068] FIG. 10 is an illustration 1000 of an exemplary user interface 1007 for a vehicle in a platoon to request an adjustment to a platoon control parameter (or transmit control commands to the lead vehicle). For one embodiment, the lead vehicle of a platoon may receive, from another platoon vehicle, information regarding a platoon control parameter. Platoon control parameters may include changing the speed 1001 up 1002 or down 1003 of each vehicle in the platoon, adjusting the lane alignment left 1005 or right 1006 by a certain amount 104 of each vehicle in the platoon, avoiding an obstacle on the left or right, or enabling or disabling stop and go mode. The lead vehicle determines whether or not to change the platoon control parameter based on the information received from the other platoon vehicle regarding the platoon control parameter. If the lead vehicle changes a platoon control parameter, the lead vehicle may transmit a platoon control parameter change message to each vehicle in the platoon so that the other vehicles will make the vehicle control change corresponding to the platoon control parameter change.

[0069] For some embodiments, a platoon control parameter change message may be transmitted to the lead vehicle. For some embodiments, a platoon control parameter change message may be transmitted to an ITS service station. A platoon control parameter change message includes information regarding a platoon control parameter. For some embodiments, determining to change a platoon control parameter may be based on the information received regarding the platoon control parameter. For some embodiments, determining to change the platoon control parameter may also include receiving from platoon vehicles information regarding a platoon control parameter, determining which received information is the most accurate, and changing the platoon control parameter based on the most accurate received information regarding the platoon control parameter. When a platoon control parameter is changed, the change is transmitted to each vehicle in the platoon, such that each vehicle uses the new platoon control parameter value for applicable operations. [0070] For some embodiments, information transmitted to the lead vehicle by other vehicles may include sensor data or video data recorded by another vehicle. For other embodiments, the lead vehicle may receive environment perception system data or vehicle computer system data from other vehicles in the platoon. The lead vehicle may determine the most accurate measurement data (including sensor and video data) or the vehicle using the best object detection algorithms and use data under those scenarios.

[0071] Mixed traffic scenarios may exist with vehicles using different automation levels and different vehicle types (passenger cars, trucks, and other vehicles). Transport infrastructure may not be adapted fully to these scenarios for several years, and long platoons may encounter problems with narrow bridges and road construction (or maintenance work) zones. The problem may become more acute when automation allows drivers to pay attention to things other than driving. For these scenarios, splitting a platoon into two or more mini-platoons or changing the lead vehicle to other vehicles with more alert drivers may be helpful.

[0072] A lead vehicle's computer system may send support requests to other drivers in the platoon. A triggering signal that triggers a platoon reconfiguration process may come from an environment perception system of the lead vehicle or as a V2X communication message from other vehicles or an ITS service station.

[0073] For example, a wide cargo load may travel towards a platoon that has both trucks and passenger cars. The special transport vehicle in front of the wide cargo load warns the lead vehicle of the platoon that the wide cargo load is partly in the left lane. The lead vehicle is unable to determine the best method to handle the situation. One option splits the platoon into trucks and passenger cars. The trucks may stop to allow the wide cargo load to pass while the passenger cars continue traveling in a new platoon. Another option has the trucks take a detour while the passenger cars continue along the original route.

[0074] For one embodiment, an undetected (or unknown) object may be detected and determined to be in front of the platoon. The radar system of a vehicle approaching a platoon recognizes an object in front the vehicle. The vehicle's lidar system does not detect any objects due to rain-induced noisy sensor readings. Therefore, the object is undetected by the vehicle. The approaching vehicle sends an undetected object trigger message (or signal) to each platooning vehicle to report location of the object (which may be, for example, 400 m ahead of the platoon).

The lead vehicle determines that splitting the platoon is more optimal than bypassing or detouring around the difficult section. The lead (or supervisor) vehicle determines that the driver of the approaching vehicle is available to take control of a mini-platoon. The lead vehicle sends video data from the lead vehicle to the approaching vehicle for display on the see-through application. The lead vehicle (or a system) transmits messages to split the platoon in two via messages to the other platoon vehicles.

[0075] FIG. 11 shows a plan view schematic 1100 for one example of vehicle movement following a change of the lead vehicle in a platoon. The former lead vehicle (in the first position) moves 1104, 1105 from the lead position 1101 in the platoon to the second 1102 or third 1103 position, respectively, in the example platoon with three vehicles. The new lead vehicle moves 1106, 1107 from either the second 1102 or third 1103 position, respectively, to the lead position 1101. After the new lead vehicle and the former lead vehicle are in position, the platoon vehicles continue moving forward and resume steady state operation.

[0076] A wireless transmit/receive unit (WTRU) may be used as a vehicle control and communications unit in embodiments described herein. The network architecture shown in FIGs. 12A to 12F may be used as a communications network to transmit messages between vehicles, ITS service stations, and other external servers.

[0077] FIG. 12A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, and the like, to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel- access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0078] As shown in FIG. 12 A, the communications system 100 may include WTRUs 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a RAN 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. [0079] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0080] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple- input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0081] The base stations 114a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, and the like). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0082] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel-access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA). [0083] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE- A).

[0084] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0085] The base station 114b in FIG. 12A may be a wireless router, Home Node B, Home eNode B, or access point, as examples, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE- A, and the like) to establish a picocell or femtocell. As shown in FIG. 12A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0086] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. As examples, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, and the like, and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 12A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology. [0087] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and IP in the TCP/IP Internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0088] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 12A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0089] FIG. 12B is a system diagram of an example WTRU 102. As shown in FIG. 12B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. The transceiver 120 may be implemented as a component of decoder logic 119. For example, the transceiver 120 and decoder logic 119 can be implemented on a single LTE or LTE-A chip. The decoder logic may include a processor operative to perform instructions stored in a non-transitory computer-readable medium. As an alternative, or in addition, the decoder logic may be implemented using custom and/or programmable digital logic circuitry.

[0090] It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 12B and described herein.

[0091] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 12B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0092] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0093] In addition, although the transmit/receive element 122 is depicted in FIG. 12B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MTMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0094] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0095] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).

The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory

(RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0096] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. As examples, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel- zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li -ion), and the like), solar cells, fuel cells, and the like.

[0097] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0098] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0099] FIG. 12C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 15. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 12C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a,

140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The

RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment. [0100] As shown in FIG. 12C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0101] The core network 106 shown in FIG. 12C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0102] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices.

[0103] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0104] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0105] FIG. 12D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0106] The RAN 104 may include eNode Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode Bs while remaining consistent with an embodiment. The eNode Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode Bs 160a, 160b, 160c may implement MTMO technology. Thus, the eNode B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0107] Each of the eNode Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio-resource-management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 12D, the eNode Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0108] The core network 107 shown in FIG. 12D may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0109] The MME 162 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0110] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0111] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0112] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0113] FIG. 12E is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0114] As shown in FIG. 12E, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MTMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility-management functions, such as handoff triggering, tunnel establishment, radio-resource management, traffic classification, quality-of- service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0115] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point (not shown), which may be used for authentication, authorization, IP-host-configuration management, and/or mobility management.

[0116] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0117] As shown in FIG. 12E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility-management capabilities, as examples. The core network 109 may include a mobile-IP home agent (MTP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0118] The M P-HA 184 may be responsible for IP-address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MTP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0119] Although not shown in FIG. 12E, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point (not shown), which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point (not shown), which may include protocols for facilitating interworking between home core networks and visited core networks.

[0120] FIG. 12F depicts an example network entity 190 that may be used within the communication system 100 of FIG. 12A. As depicted in FIG. 12F, network entity 190 includes a communication interface 192, a processor 194, and non-transitory data storage 196, all of which are communicatively linked by a bus, network, or other communication path 198.

[0121] Communication interface 192 may include one or more wired communication interfaces and/or one or more wireless-communication interfaces. With respect to wired communication, communication interface 192 may include one or more interfaces such as Ethernet interfaces, as an example. With respect to wireless communication, communication interface 192 may include components such as one or more antennae, one or more transceivers/chipsets designed and configured for one or more types of wireless (e.g., LTE) communication, and/or any other components deemed suitable by those of skill in the relevant art. And further with respect to wireless communication, communication interface 192 may be equipped at a scale and with a configuration appropriate for acting on the network side— as opposed to the client side— of wireless communications (e.g., LTE communications, Wi-Fi communications, and the like). Thus, communication interface 192 may include the appropriate equipment and circuitry (perhaps including multiple transceivers) for serving multiple mobile stations, UEs, or other access terminals in a coverage area.

[0122] Processor 194 may include one or more processors of any type deemed suitable by those of skill in the relevant art, some examples including a general-purpose microprocessor and a dedicated DSP.

[0123] Data storage 196 may take the form of any non-transitory computer-readable medium or combination of such media, some examples including flash memory, read-only memory (ROM), and random-access memory (RAM) to name but a few, as any one or more types of non- transitory data storage deemed suitable by those of skill in the relevant art could be used. As depicted in FIG. 12F, data storage 196 contains program instructions 197 executable by processor 194 for carrying out various combinations of the various network-entity functions described herein.

[0124] In some embodiments, the network-entity functions described herein are carried out by a network entity having a structure similar to that of network entity 190 of FIG. 12F. In some embodiments, one or more of such functions are carried out by a set of multiple network entities in combination, where each network entity has a structure similar to that of network entity 190 of

FIG. 12F. In various different embodiments, network entity 190 is— or at least includes— one or more of (one or more entities in) RAN 103, (one or more entities in) RAN 104, (one or more entities in) RAN 105, (one or more entities in) core network 106, (one or more entities in) core network 107, (one or more entities in) core network 109, base station 114a, base station 114b,

Node-B 140a, Node-B 140b, Node-B 140c, RNC 142a, RNC 142b, MGW 144, MSC 146, SGSN 148, GGSN 150, eNode B 160a, eNode B 160b, eNode B 160c, MME 162, serving gateway 164, PDN gateway 166, base station 180a, base station 180b, base station 180c, ASN gateway 182, MIP-HA 184, AAA 186, and gateway 188. And certainly other network entities and/or combinations of network entities could be used in various embodiments for carrying out the network-entity functions described herein, as the foregoing list is provided by way of example and not by way of limitation.

[0125] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer- readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0126] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD- ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.